gissuebot
commented
9 years ago Original comment posted by kevinb@google.com on 2013-09-11 at 05:12 PM
What's happening at WeldConstructorImpl.java:103?
Closed gissuebot closed 9 years ago
gissuebot
commented
9 years ago Original comment posted by kevinb@google.com on 2013-09-11 at 05:12 PM
What's happening at WeldConstructorImpl.java:103?
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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: Research
Labels: Type-Defect, Package-General
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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
gissuebot
commented
9 years ago 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>)]
gissuebot
commented
9 years ago 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]]
gissuebot
commented
9 years ago 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)
gissuebot
commented
9 years ago 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().
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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?
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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)?
gissuebot
commented
9 years ago 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 https://github.com/google/guava/issues/1433
gissuebot
commented
9 years ago 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
gissuebot
commented
9 years ago 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/
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago 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
gissuebot
commented
9 years ago 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).
gissuebot
commented
9 years ago 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
gissuebot
commented
9 years ago 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.
gissuebot
commented
9 years ago
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