glassfish
  1. glassfish
  2. GLASSFISH-20850

classloader favors modules/guava.jar over guava library in the ear

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0
    • Fix Version/s: None
    • Component/s: cdi, classloader
    • Labels:
      None

      Description

      I tried to upgrad the guava library in our application to version 15-0. When I deploy the application on glassfish 4.0, I see the following Exception:

      Caused by: java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch;
      at MyClient.buildClient(MyClient.java:159)
      at MyClient.initClient(MyClient.java:143)
      at MyClient.<init>(MyClient.java:74)
      at MyClient.<init>(MyClient.java:62)
      at MyClientFactory.createClient(MyClientFactory.java:12)
      at MyClientProducer.createClient(MyClientProducer.java:16)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:606)
      at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)

      To verify where the class is loaded from, I added:
      URL resource = this.getClass().getClassLoader()
      .getResource(Stopwatch.class.getName().replaceAll("
      .", "/") + ".class");
      LOGGER.info("URL for Stopwatch:" + resource.toString());
      which gives me
      URL for Stopwatch:bundle://108.0:1/com/google/common/base/Stopwatch.class

      MyClient, MyClientFactory and MyClientProducer are all inside an ejb jar file.
      guava-15.0.jar is in a lib folder next to the ejb jar (with lib/guava-15.0.jar in the ear META-INF/MANIFEST.MF Class-Path)

      All other libraries there can be found. It just seems, that the weld classloader favors the guava.jar bundled with glassfish 4 over the one I provide for the application. I would expect the classloader to give stuff deployed with the ear a higher priority.

        Issue Links

          Activity

          Hide
          lprimak added a comment -

          Just to recap the current status of this issue:
          JARs in GF modules/ directory erroneously take precedence of JARs in user specified applications
          Examples:

          • guava.jar
          • jackson-*.jar
          • Others?

          Here are the current observations:

          •  <class-loader delegate="false"/> 

            works correctly for, but only for WAR files that have guava.jar and other JARs in it's lib/ directory

          • does NOT work correctly if updated JARs are in domain/lib directory
          • vps's patch above works correctly, but only for skinny WARs or EJB-JARs inside EAR files
          • simon.schlachter's patch above was not tested due to it's implementation complexity
          Show
          lprimak added a comment - Just to recap the current status of this issue: JARs in GF modules/ directory erroneously take precedence of JARs in user specified applications Examples: guava.jar jackson-*.jar Others? Here are the current observations: <class-loader delegate= " false " /> works correctly for, but only for WAR files that have guava.jar and other JARs in it's lib/ directory does NOT work correctly if updated JARs are in domain/lib directory vps's patch above works correctly, but only for skinny WARs or EJB-JARs inside EAR files simon.schlachter's patch above was not tested due to it's implementation complexity
          Hide
          lprimak added a comment -

          Payara team is actively working to fix this issue

          Show
          lprimak added a comment - Payara team is actively working to fix this issue
          Hide
          Thomas Andres added a comment -

          Thanks for the information. Is there a payara issue to track for news regarding this issue?

          Show
          Thomas Andres added a comment - Thanks for the information. Is there a payara issue to track for news regarding this issue?
          Show
          lprimak added a comment - Yes, Thomas, https://github.com/payara/Payara/issues/419 https://github.com/payara/Payara/issues/431
          Hide
          lprimak added a comment - - edited

          This issue is now fixed in Payara, should be out with the next release (.162)
          The functionality is enabled globally with system property:

          fish.payara.classloading.delegate=false
          

          similar to configuration in glassfish-web.xml

          Also, the functionality can be enabled in individual EAR files with the entry:

          <classloading-delegate>false</classloading-delegate>
          

          in glassfish-application.xml

          Show
          lprimak added a comment - - edited This issue is now fixed in Payara, should be out with the next release (.162) The functionality is enabled globally with system property: fish.payara.classloading.delegate= false similar to configuration in glassfish-web.xml Also, the functionality can be enabled in individual EAR files with the entry: <classloading-delegate> false </classloading-delegate> in glassfish-application.xml

            People

            • Assignee:
              Romain Grécourt
              Reporter:
              Thomas Andres
            • Votes:
              18 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated: