5 Replies Latest reply: Jul 15, 2010 3:45 PM by Dan Allen RSS

Container versions in extensions

Dan Allen Master

We are having a discussion in ARQ-200 about how to incorporate the supported container version into an integration. The discussion made us aware of the fact that ShrinkWrap doesn't include the version of the container it's linking against in the extension name at all. I think at the very least we should include the major version number in the extension name, introducing a new version number only when there is an incompatible API change in the container.

 

When selecting an integration, you choose the integration with the highest container version that isn't greater than the container you are targeting. In other words, if the following two ShrinkWrap extensions were available:

 

  • extension-jetty-6
  • extension-jetty-8

 

You could use extension-jetty-6 for Jetty >= 6.0 and Jetty < 8.0, but use extension-jetty-8 for Jetty 8.0 and up. The extension-jetty-8 would exist for good reason.

 

I propose the following name changes for integrations I've recently worked on:

 

  • extension-jetty => extension-jetty-6.1
  • extension-tomcat => extension-tomcat-6

 

The minor version is only included if the .0 release is not compatible. That's why it's extension-jetty-6.1 and not extension-jetty-6 (we would need a new implementation for Jetty 6.0). Basically, be as non-specific as possible.

 

(I'm open to including .0 as well for clarity, i.e., extension-tomcat-6.0).

  • 1. Re: Container versions in extensions
    Andrew Rubinger Master

    Good catch.

     

    I think Major and minor should be nice, in case compatibility is broken inbetween.  We can only hope no one breaks in a patch release.

     

    S,

    ALR

  • 2. Re: Container versions in extensions
    Dan Allen Master

    I've implemented this for the Tomcat and Jetty extensions. I followed the same pattern we are using in Arquillian...cite the earliest major version that is compatible, and only include a minor version if it is warranted.

     

    • extension-tomcat-6
    • extension-jetty-6
    • extension-jetty-7

  • 3. Re: Container versions in extensions
    Aslak Knutsen Master

    Dan Allen wrote:

     

    I've implemented this for the Tomcat and Jetty extensions. I followed the same pattern we are using in Arquillian...cite the earliest major version that is compatible, and only include a minor version if it is warranted.

     

     

    • extension-tomcat-6
    • extension-jetty-6
    • extension-jetty-7

     

    Just to make sure..

     

    Arquillian has Jetty 6.1

    ShrinkWrap has Jetty 6

     

    Of course it could be perfectly explained by: Other APIs needed by the Arquillian Container besides the Deployment APIs has changed from 6.0 to 6.1. But, is that the case?

     

     

  • 4. Re: Container versions in extensions
    Andrew Rubinger Master

    Super, SHRINKWRAP JIRA now reflects this.

     

    S,

    ALR

  • 5. Re: Container versions in extensions
    Dan Allen Master

    Aslak Knutsen wrote:

     

    Dan Allen wrote:

     

    I've implemented this for the Tomcat and Jetty extensions. I followed the same pattern we are using in Arquillian...cite the earliest major version that is compatible, and only include a minor version if it is warranted.

     

     

    • extension-tomcat-6
    • extension-jetty-6
    • extension-jetty-7

     

    Just to make sure..

     

    Arquillian has Jetty 6.1

    ShrinkWrap has Jetty 6

     

    Of course it could be perfectly explained by: Other APIs needed by the Arquillian Container besides the Deployment APIs has changed from 6.0 to 6.1. But, is that the case?

     

     

     

    That's exactly the case. The JNDI naming changed in Jetty 6.1, an API which Arquillian uses. The WebAppContext itself has remained unchanged from Jetty 6.0.0. I just verified this. So the ShrinkWrap extension has the broader version support.