Guava 15 cannot be deployed in an environment using CDI 1.0 such as JEE6 #1527
Comments
|
Original comment posted by kevinb@google.com on 2013-09-11 at 05:12 PM What's happening at WeldConstructorImpl.java:103? |
|
Original comment posted by kevinb@google.com on 2013-09-11 at 05:15 PM I understand the Guava upgrade may be tickling this somehow, but the problem is still likely in the jboss code. Let's see what it's doing that's getting a bad array index. |
|
Original comment posted by cgdecker@google.com on 2013-09-11 at 05:39 PM Ok, I found a Weld bug describing this exact issue: https://issues.jboss.org/browse/WELD-1007 It's a very strange issue: constructor.getParameterTypes().length is not equal to constructor.getParameterAnnotations().length, something I wouldn't have thought possible. An explanation of the fix on Github explains: If the class is a non-static inner class, the methods behave like this:
That said, the last comment on that bug makes me think this could in fact have to do with the beans.xml added to the Guava jar. Going to investigate that now. Status: |
|
Original comment posted by cgdecker@google.com on 2013-09-11 at 05:48 PM Ok, I've confirmed that it's the presence of beans.xml in Guava 15.0 that's causing this. |
|
Original comment posted by info.russevent on 2013-09-12 at 08:43 AM We have similar problem, but on Weblogic <Sep 11, 2013 6:35:40 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../../_WL_user/ui/6w854l/war/WEB-INF/lib/guava-15.0.jar!/META-INF/beans.xml@5 against xsd. schema_reference.4: Failed to read schema document 'http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.>
|
|
Original comment posted by simschla on 2013-09-13 at 02:26 PM We have a similar issue on Glassfish 3.1.2.2. During deployment of our App we get the following exception: [#|2013-09-13T16:22:18.070+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=46;_ThreadName=Thread-2;|Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[parameter 1] of [constructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)] |
|
Original comment posted by slavus on 2013-09-18 at 07:26 PM Same problem on Websphere Liberty Profile [ERROR ] Api type [java.util.Set] is not found with the qualifiers |
|
Original comment posted by emond.papegaaij on 2013-09-24 at 10:35 AM It seems the namespace used in beans.xml is also wrong. Guava 15.0 can no longer be used in projects with solder: |
|
Original comment posted by emond.papegaaij on 2013-09-24 at 11:26 AM I'm wondering why ServiceManager has a contructor with an injected set of Services rather than an Instance<Service>. Instance<Service> is Iterable and you can check if it isUnsatisfied(). |
|
Original comment posted by cgdecker@google.com on 2013-09-25 at 06:33 PM @emond.papegaaij: I'll take a look at the namespace issue. As far as Instance<Service>: Instance is a CDI-specific interface. Guava just uses JSR-330. |
|
Original comment posted by emond.papegaaij on 2013-09-25 at 10:18 PM The namespace has changed from CDI 1.0 to 1.1, java.sun.com was used for jee6, xmlns.jcp.org is used for jee7. This means that the current implementation will only be understood by jee7. CDI 1.0 implementations will still see the presence of beans.xml, which acts as a marker to enable CDI for that jar, but will not understand bean-discovery-mode="none". In effect, this beans.xml disables discovery for CDI 1.1 but enables it for CDI 1.0. CDI 1.0 does not allow excluding certain beans (or jars) from discovery (except by NOT providing a beans.xml). Perhaps the JSR-330 interface Provider might work. It is not iterable, but a Provider<Service> is injected as a Instance<Service>, which is Iterable. It's documentation states you can use it to inject multiple instances, but I can't find any example on how to do that. Injecting a Provider and calling get() fails with an exception if the dependency is not satisfied. |
|
Original comment posted by cgdecker@google.com on 2013-09-30 at 03:29 PM @emond.papegaaij: By "the namespace used in beans.xml is also wrong", do you mean that the namespace used is correct for CDI 1.1 but different than the namespace used for CDI 1.0? Because the beans.xml appears to be using the correct CDI 1.1 xmlns.jcp.org namespace. It sounds like the change in namespace from CDI 1.0 to CDI 1.1 is the problem rather than anything Guava-specific? |
|
Original comment posted by emond.papegaaij on 2013-09-30 at 06:35 PM Yes, I initially thought the namespace was wrong, but that's because we are still bound to CDI 1.0. As can be seen on http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html#7 , all Java EE namespaces have changed: "All new schemas are in the http://xmlns.jcp.org/xml/ns/javaee/ namespace. Most older schemas remain in the http://java.sun.com/xml/ns/javaee/ namespace.". Using the CDI 1.1 namespace, will break Guava for everyone using CDI 1.0, which is not that uncommon, because Glassfish is the only JEE7 server. We deploy on JBoss, and Wildfly 8 is still in alpha. JBoss 7 comes with CDI 1.0. As I've said in comment 11, the current beans.xml fixes issue issue #1433 for CDI 1.1 but breaks it for CDI 1.0. Solder seems to make things even worse, because it does not recognize the namespace and throws an exception, causing deployment to fail. That's not Guava's fault. We should start migrating to Apache DeltaSpike, which probably fixes the exception. |
|
Original comment posted by xaerxess on 2013-10-04 at 07:45 AM Is there any workaround to this problem (I'm referring to Guava 15 JBoss 7.1.1 deployment issue)? |
|
Original comment posted by emond.papegaaij on 2013-10-04 at 07:59 AM To fix the unsatisfied dependency, you can use the workaround in #1433 |
|
Original comment posted by cgdecker@google.com on 2013-10-28 at 05:13 PM Sorry for the delay on this. I've just released a new Guava 15.0 artifact with classifier "cdi1.0" to Maven Central. It's identical to the normal Guava 15.0 jar, but with no beans.xml file, so it should work in an environment that uses CDI 1.0. The dependency can be specified as: <dependency> The new artifact probably won't show up in Central for a few hours at least (15.0 took a few days for some reason), but I'll update this issue when I see that it's there. Status: |
|
Original comment posted by cgdecker@google.com on 2013-10-28 at 07:49 PM Update: It's not showing up on search.maven.org yet, but guava-15.0-cdi1.0.jar is showing up here now and should be usable: http://central.maven.org/maven2/com/google/guava/guava/15.0/ |
|
Original comment posted by sebastian.davids on 2013-10-29 at 01:00 PM Please add a note to the WIKI pages/release notes/project page. |
|
Original comment posted by cgdecker@google.com on 2013-10-29 at 03:59 PM Added: https://code.google.com/p/guava-libraries/wiki/Release15#A_note_on_JEE6_/_CDI_1.0 |
|
Original comment posted by cgdecker@google.com on 2013-10-30 at 10:10 PM JSR-330 annotations have been removed for Guava 16.0, so hopefully there will be no further issues with CDI. Now we'll just have issues when code that was taking advantage of the annotations stops working. |
|
Original comment posted by kumar.vijay1 on 2014-01-16 at 03:59 PM I see the same issue in JBossAS 7.1.1.Final |
|
Original comment posted by cgdecker@google.com on 2014-01-16 at 04:41 PM @kumar.vijay1: Are you using guava-15.0-cdi1.0? That should fix it. Alternatively, guava-16.0-rc1 is also out (and should work with any version of CDI, since it has no JSR-330 annotations). |
|
Original comment posted by kumar.vijay1 on 2014-01-16 at 07:29 PM Thanks for your suggestion cgdecker, the 16.0-rc1 worked fine so did version 14.0 |
|
Original comment posted by dharkness on 2014-03-17 at 10:36 PM I was getting the same error about Set<Service> on WildFly 8.0.0.Final with Guava 14.0.1, and upgrading to 16.0.1 resolved the issue. |
|
Original comment posted by har...@yahoo-inc.com on 2014-08-09 at 01:07 AM where did you upgrade it? |
gissuebot
added
type=defect
Original issue created by thomas.lorblanches on 2013-09-11 at 12:49 PM
I had no problem previously with Guava 14.0.1, but with the new Guava 15.0 my application cannot be deployed anymore on JBoss AS 7.1.1.
Maybe this is linked to issue #1433 ?
Here is the stacktrace:
14:44:39,174 ERROR [org.jboss.msc.service.fail](MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit.
"ResourceIT.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."ResourceIT.war".WeldService:
com.google.common.collect.ComputationException: java.lang.ArrayIndexOutOfBoundsException: 3
at org.jboss.as.weld.services.WeldService.start(WeldService.java:83)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2
.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: com.google.common.collect.ComputationException: java.lang.ArrayIndexOutOfBoundsException: 3
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:397)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149)
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:139)
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118)
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49)
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149)
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:139)
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118)
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49)
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115)
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
... 5 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 3
at org.jboss.weld.introspector.jlr.WeldConstructorImpl.<init>(WeldConstructorImpl.java:103)
at org.jboss.weld.introspector.jlr.WeldConstructorImpl.of(WeldConstructorImpl.java:66)
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:205)
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118)
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49)
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
... 32 more
The text was updated successfully, but these errors were encountered: