I'm not implementing guava. I use guave-15.0, as I've written in the
referenced JIRA. Description from the JIRA: 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.(MyClient.java:74) at
MyClient.(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.
--
[Message sent by forum member 'tandres19']
View Post: http://forums.java.net/node/884793