GoogleCodeExporter
commented
9 years ago What's happening at WeldConstructorImpl.java:103?Original comment by kevinb@google.com on 11 Sep 2013 at 5:12
Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago What's happening at WeldConstructorImpl.java:103?Original comment by kevinb@google.com on 11 Sep 2013 at 5:12
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago
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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago @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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago @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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago To fix the unsatisfied dependency, you can use the workaround in
https://code.google.com/p/guava-libraries/issues/detail?id=1433#c20Original comment by emond.pa...@gmail.com on 4 Oct 2013 at 7:59
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago Added:
https://code.google.com/p/guava-libraries/wiki/Release15#A_note_on_JEE6_/_CDI_1.
0Original comment by cgdecker@google.com on 29 Oct 2013 at 3:59
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago I see the same issue in JBossAS 7.1.1.FinalOriginal comment by kumar.vi...@gmail.com on 16 Jan 2014 at 3:59
GoogleCodeExporter
commented
9 years ago @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
GoogleCodeExporter
commented
9 years ago [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
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago where did you upgrade it?
Original comment by har...@yahoo-inc.com on 9 Aug 2014 at 1:07
GoogleCodeExporter
commented
9 years ago 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
GoogleCodeExporter
commented
9 years ago Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08
Original issue reported on code.google.com by
thomas.l...@gmail.comon 11 Sep 2013 at 12:49