glassfish
  1. glassfish
  2. GLASSFISH-9165

Application bundling Jersey 1.0 is forced to use GF's copy of Jersey

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: classloader
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      9,165

      Description

      Dropping the artifactory.war [1] in v3's autodeploy directory triggers the following scan error documented at http://forums.java.net/jive/thread.jspa?
      messageID=360993.

      This is a case of an application being forced to use Jersey 1.1 bundled in GlassFish v3 instead of the 1.0 library that it ships with.
      Even with class loader delegation set to false Jersey 1.0 will look in META-INF/services of jersey installed in GF.

      Of course it would be nice to have Jersey 1.0 apps run unmodified on 1.1 but only strict adherence to the JAX-RS specification offers compatibility
      between 1.0 and 1.1 releases.

      Removing jersey from the GFv3 distro sounds like a bad solution (glassfish-management depends on it).

      An application should be able to ship and use its own set of libraries with some sort of "ignore system/GlassFish libraries" isolation at deploy time.

      [1]: http://downloads.sourceforge.net/project/artifactory/artifactory/2.0/artifactory-2.0.7.war

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        OK, I looked at your simplified test case. What you are seeing is a direct
        result of switching of classloader delegation by setting delagation=false in
        sun-web.xml. I have said this before, I understand why things won't work as
        expected when delegation is switched off. Switching off delegation must be a
        developer's last resort, as it can lead to all kinds of class constraint
        violations.

        Run your simple test case with delegation=true (this is the default value) and
        tell me what you see. Do you see two versions of
        com.sun.jersey.spi.HeaderDelegateProvider.class?

        Show
        Sanjeeb Sahoo added a comment - OK, I looked at your simplified test case. What you are seeing is a direct result of switching of classloader delegation by setting delagation=false in sun-web.xml. I have said this before, I understand why things won't work as expected when delegation is switched off. Switching off delegation must be a developer's last resort, as it can lead to all kinds of class constraint violations. Run your simple test case with delegation=true (this is the default value) and tell me what you see. Do you see two versions of com.sun.jersey.spi.HeaderDelegateProvider.class?
        Hide
        sandoz added a comment -

        Class loader delegation set to true works, but... I feel we may be going around
        in circles

        The war depends Jersey 1.0 APIs in Jersey 1.0 jars to function correctly,
        which is why class loader delegation was set to false, so that the Jersey 1.0
        jars take precedence.

        The war depends on the Jersey Spring integration. Which is why when class loader
        delegation is set to true for the war the following exception is thrown:

        SEVERE: WebModule[/artifactory]StandardWrapper.Throwable
        java.lang.NoSuchMethodError:
        com.sun.jersey.spi.container.WebApplication.initiate(Lcom/sun/jersey/api/core/ResourceConfig;Lcom/sun/jersey/spi/service/ComponentProvider;)V
        at
        org.artifactory.rest.servlet.ArtifactoryRestServlet.initiate(ArtifactoryRestServlet.java:51)
        at
        com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:242)
        at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:455)
        at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:178)
        at
        com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:281)
        at
        com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:442)
        at javax.servlet.GenericServlet.init(GenericServlet.java:242)

        (See the attachment that Alexis added).

        The ArtifactoryRestServlet is extending the Jersey 1.0 ServletContainer, but in
        Jersey 1.1.x the ServletContainer class has changed.

        The only way this war will work on GF is if:

        1) Jersey in GF is removed; or

        2) They developers upgrade their app to the same version as in GF.

        I fear are going to run into this issue again and again when GF is released
        and potentialy in the future as well, if refactoring of service impl classes
        occurs in later versions.

        Unfortunately this the Java equivalent of DLL hell. Again, we need a way of
        cleanly isolating web app deployments.

        Show
        sandoz added a comment - Class loader delegation set to true works, but... I feel we may be going around in circles The war depends Jersey 1.0 APIs in Jersey 1.0 jars to function correctly, which is why class loader delegation was set to false, so that the Jersey 1.0 jars take precedence. The war depends on the Jersey Spring integration. Which is why when class loader delegation is set to true for the war the following exception is thrown: SEVERE: WebModule [/artifactory] StandardWrapper.Throwable java.lang.NoSuchMethodError: com.sun.jersey.spi.container.WebApplication.initiate(Lcom/sun/jersey/api/core/ResourceConfig;Lcom/sun/jersey/spi/service/ComponentProvider;)V at org.artifactory.rest.servlet.ArtifactoryRestServlet.initiate(ArtifactoryRestServlet.java:51) at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:242) at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:455) at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:178) at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:281) at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:442) at javax.servlet.GenericServlet.init(GenericServlet.java:242) (See the attachment that Alexis added). The ArtifactoryRestServlet is extending the Jersey 1.0 ServletContainer, but in Jersey 1.1.x the ServletContainer class has changed. The only way this war will work on GF is if: 1) Jersey in GF is removed; or 2) They developers upgrade their app to the same version as in GF. I fear are going to run into this issue again and again when GF is released and potentialy in the future as well, if refactoring of service impl classes occurs in later versions. Unfortunately this the Java equivalent of DLL hell. Again, we need a way of cleanly isolating web app deployments.
        Hide
        dochez added a comment -

        providing a complete application isolation is not a supported feature of V3, public libraries should not
        break public APIs during a .dot release. We should provide a solution for this problem in the next release.

        Show
        dochez added a comment - providing a complete application isolation is not a supported feature of V3, public libraries should not break public APIs during a .dot release. We should provide a solution for this problem in the next release.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.
        Hide
        Tom Mueller added a comment -

        Assigning to the classloader component for evaluation.

        Show
        Tom Mueller added a comment - Assigning to the classloader component for evaluation.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            Alexis MP
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: