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:

• constructor.getParameterTypes() returns the VM signature of the constructor (in the case of non-static inner classes: outer class + the actual parameters)
• constructor.getGenericParameterTypes() is tricky, because the array it returns depends on whether any of the constructor's parameters use generics (see http://bugs.sun.com/view_bug.do?bug_id=5087240):
• if any of the constructor's parameters use generics (e.g. Constructor(List<String> list)): constructor.getGenericParameterTypes() returns the outer class + the actual parameters
• if none of the constructor's parameters use generics (e.g. Constructor(List list): constructor.getGenericParameterTypes() returns ONLY the actual parameters
• constructor.getParameterAnnotations() is tricky in the same way as above, but it depends on whether any of the parameters has an annotation or not

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: Research
Labels: Type-Defect, Package-General

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>.>
<Sep 11, 2013 6:35:40 PM CEST> <Error> <Cluster> <BEA-000109> <An error occurred while sending multicast message: java.io.NotSerializableException: com.sun.jersey.server.impl.cdi.CDIExtension.
java.io.NotSerializableException: com.sun.jersey.server.impl.cdi.CDIExtension
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1165)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:331)
        at weblogic.common.internal.WLObjectOutputStream.writeObjectWL(WLObjectOutputStream.java:100)
        at weblogic.cluster.BasicServiceOffer.writeExternal(BasicServiceOffer.java:161)
        at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1442)
        Truncated. see log file for complete stacktrace

<Sep 11, 2013 6:38:50 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../..//tmp/_WL_user/msui/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>.>
<Sep 11, 2013 6:41:59 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../..//tmp/_WL_user/msui/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>.>
<Sep 11, 2013 6:45:08 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../..//tmp/_WL_user/msui/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>.>
<Sep 11, 2013 6:48:17 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../..//tmp/_WL_user/msui/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>.>
<Sep 11, 2013 6:51:26 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../..//tmp/_WL_user/msui/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>.>
<Sep 11, 2013 6:54:35 PM CEST> <Warning> <org.jboss.weld.Bootstrap> <BEA-000000> <WELD-001208 Warning when validating zip:/../../../../..//tmp/_WL_user/msui/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>.>
<Sep 11, 2013 6:54:35 PM CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID "1378917145607" for task "35". Error is: "weblogic.management.DeploymentException: "
weblogic.management.DeploymentException:
        at weblogic.application.internal.BaseDeployment.throwAppException(BaseDeployment.java:123)
        at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:239)
        at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:61)
        at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
        at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
        Truncated. see log file for complete stacktrace
Caused By: java.lang.NoSuchMethodException: com.google.common.base.internal.Finalizer.startFinalizer(java.lang.Class, java.lang.ref.ReferenceQueue, java.lang.ref.PhantomReference)
        at java.lang.Class.getMethod(Class.java:1632)
        at com.google.common.base.FinalizableReferenceQueue.getStartFinalizer(FinalizableReferenceQueue.java:302)
        at com.google.common.base.FinalizableReferenceQueue.<clinit>(FinalizableReferenceQueue.java:90)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:249)
        Truncated. see log file for complete stacktrace

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>)]
org.jboss.weld.exceptions.DeploymentException: 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
Qualifiers: [@javax.enterprise.inject.Default()]
for injection into Constructor Injection Point, constructor name : com.google.common.util.concurrent.ServiceManager, Bean Owner : [ServiceManager, Name:null, WebBeans Type:MANAGED, API Types:[java.lang.Object,com.google.common.util.concurrent.ServiceManager], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]]
Api type [java.util.Set] is not found with the qualifiers
Qualifiers: [@javax.enterprise.inject.Default()]
for injection into Constructor Injection Point, constructor name : com.google.common.util.concurrent.ServiceManager, Bean Owner : [ServiceManager, Name:null, WebBeans Type:MANAGED, API Types:[java.lang.Object,com.google.common.util.concurrent.ServiceManager], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]]

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:
org.jboss.solder.config.xml.util.XmlConfigurationException: Wrong root namespace for XML config file, expected:urn:java:ee, http://java.sun.com/xml/ns/javaee or no namespace, found:http://xmlns.jcp.org/xml/ns/javaee at vfs:/home/papegaaij/jboss-as-7.1.4.Final-SNAPSHOT/standalone/deployments/digdag-midoffice.war/WEB-INF/lib/guava-15.0.jar/META-INF/beans.xml:5
    at org.jboss.solder.config.xml.model.ModelBuilder.build(ModelBuilder.java:72)
    at org.jboss.solder.config.xml.bootstrap.XmlConfigExtension.beforeBeanDiscovery(XmlConfigExtension.java:93)
    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.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
    at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
    at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
    at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
    at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
    at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
    at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
    at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
    at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
    at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
    at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
    at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46)
    at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:46)
    at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:335)
    at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
    at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)

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>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>15.0</version>
  <classifier>cdi1.0</classifier>
</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: Fixed

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?