Closed GoogleCodeExporter closed 9 years ago
What's happening at WeldConstructorImpl.java:103?
Original comment by kevinb@google.com
on 11 Sep 2013 at 5:12
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 by kevinb@google.com
on 11 Sep 2013 at 5:15
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.
Original comment by cgdecker@google.com
on 11 Sep 2013 at 5:39
Ok, I've confirmed that it's the presence of beans.xml in Guava 15.0 that's
causing this.
Original comment by cgdecker@google.com
on 11 Sep 2013 at 5:48
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!/ME
TA-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!/ME
TA-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!/ME
TA-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!/ME
TA-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!/ME
TA-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!/ME
TA-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 by info.rus...@gmail.com
on 12 Sep 2013 at 8:43
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.to
ols.admin.org.glassfish.deployment.admin|_ThreadID=46;_ThreadName=Thread-2;|Exce
ption 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 by simsc...@gmail.com
on 13 Sep 2013 at 2:26
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 by sla...@gmail.com
on 18 Sep 2013 at 7:26
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 by emond.pa...@gmail.com
on 24 Sep 2013 at 10:35
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 by emond.pa...@gmail.com
on 24 Sep 2013 at 11:26
@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 by cgdecker@google.com
on 25 Sep 2013 at 6:33
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 by emond.pa...@gmail.com
on 25 Sep 2013 at 10:18
@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 by cgdecker@google.com
on 30 Sep 2013 at 3:29
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 by emond.pa...@gmail.com
on 30 Sep 2013 at 6:35
Is there any workaround to this problem (I'm referring to Guava 15 JBoss 7.1.1
deployment issue)?
Original comment by xaerx...@gmail.com
on 4 Oct 2013 at 7:45
To fix the unsatisfied dependency, you can use the workaround in
https://code.google.com/p/guava-libraries/issues/detail?id=1433#c20
Original comment by emond.pa...@gmail.com
on 4 Oct 2013 at 7:59
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.
Original comment by cgdecker@google.com
on 28 Oct 2013 at 5:13
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 by cgdecker@google.com
on 28 Oct 2013 at 7:49
Please add a note to the WIKI pages/release notes/project page.
Original comment by sebastia...@gmail.com
on 29 Oct 2013 at 1:00
Added:
https://code.google.com/p/guava-libraries/wiki/Release15#A_note_on_JEE6_/_CDI_1.
0
Original comment by cgdecker@google.com
on 29 Oct 2013 at 3:59
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 by cgdecker@google.com
on 30 Oct 2013 at 10:10
I see the same issue in JBossAS 7.1.1.Final
Original comment by kumar.vi...@gmail.com
on 16 Jan 2014 at 3:59
@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 by cgdecker@google.com
on 16 Jan 2014 at 4:41
[deleted comment]
Thanks for your suggestion cgdecker, the 16.0-rc1 worked fine so did version
14.0
Original comment by kumar.vi...@gmail.com
on 16 Jan 2014 at 7:29
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 by dharkn...@gmail.com
on 17 Mar 2014 at 10:36
where did you upgrade it?
Original comment by har...@yahoo-inc.com
on 9 Aug 2014 at 1:07
This issue has been migrated to GitHub.
It can be found at https://github.com/google/guava/issues/<issue id>
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:12
Original comment by cgdecker@google.com
on 3 Nov 2014 at 9:08
Original issue reported on code.google.com by
thomas.l...@gmail.com
on 11 Sep 2013 at 12:49