I updated from guava 14.0.1 to 15.0 in an application that deploys on WebLogic 12c, and I get a java.lang.NoSuchMethodException during deployment that I've been unable to resolve:
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:1624)
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:266)
at com.oracle.injection.provider.weld.BasicResourceLoader.classForName(BasicResourceLoader.java:27)
at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:107)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:77)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135)
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349)
at com.oracle.injection.provider.weld.WeldInjectionContainer.deploy(WeldInjectionContainer.java:99)
at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:68)
at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:47)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:37)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:586)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:148)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:114)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:339)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:846)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1275)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:442)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:176)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
I already have been using the WebLogic prefer-application-packages classloader filtering in my weblogic.xml file as described here in order to resolve a runtime conflict in WebLogic 12c as it seems to repackage an older version of the library. This had been working in guava 14.0.1, but does not in 15.0.
As far as I can tell, preferring the com.google.common.* package should include everything. Does this Finalizer class do something special that is happening before the classloader filtering happens, thereby trying to load the old version that appears to have a different API?
Is there an alternative solution to use the guava-15.0.jar packaged with the application instead of what is bundled with the server?
There's an open issue #1527 targeting this problem (Guava 15 cannot be deployed to any JEE6 container) which occured after fixing this one. Please star and / or comment and wait for the fix (comment #33 suggests that version 15.0.1 could be released in near furture).
EDIT:
Meanwhile, the issue was resolved by new maven release:
A note on JEE6 / CDI 1.0
A workaround added in Guava 15.0 to make it compatible with CDI 1.1
(used in JEE7 containers) caused problems for Guava with CDI 1.0 (used
in JEE6 containers).
If you're using Guava in a CDI 1.0 environment, you should use
guava-15.0-cdi1.0.jar instead of the normal Guava jar. In Maven, the
dependency can be specified as:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
<classifier>cdi1.0</classifier>
</dependency>
If you want to deploy on both JEE 6 and 7 servers, you must use Guava 13 or wait until 16 is released.
As an aditional information, I landed on this question with a similar problem while upgrading to Weblogic 12c due to a conflit between WL and Guava (have tried with versions 11 and 18 of Guava).
I found the solution to be to explicitly prefer my application's lib. I set this on my weblogic.xml:
<prefer-application-packages>
<package-name>com.google.common</package-name>
</prefer-application-packages>
Look at http://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#WLPRG315 for the reference.
Related
My Java Spring Boot project fails at startup with the given error:
Failed to instantiate [io.r2dbc.spi.ConnectionFactory]: Factory method 'connectionFactory' threw exception; nested exception is java.lang.NoSuchFieldError: LOCK_WAIT_TIMEOUT
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-r2dbc</artifactId>
<version>1.4.3</version>
</dependency>
<dependency>
<groupId>com.oracle.database.r2dbc</groupId>
<artifactId>oracle-r2dbc</artifactId>
<version>0.4.0</version>
</dependency>
How do I fix it?
tl;dr: As of this writing, use oracle-r2dbc 0.1.0 in Spring projects.
oracle-r2dbc 0.4.0 depends on a newer version of io.r2dbc:r2dbc-spi than spring-data-r2dbc 1.4.3.
You may have to clear your build tool or IDE's cache for the change to take effect. (In my case mvn clean and IntelliJ "Invalidate Caches...")
Btw, when I downgraded, I think it broke using descriptors in the rdbc URL so I had to switch to a URL like this: r2dbc:oracle://<host>:<port>/<service-name>
Update, just saw on Oracle's driver docs for r2dbc, it says:
Use the 0.1.0 version of Oracle R2DBC if you are programming with
Spring. The later versions of Oracle R2DBC implement the 0.9.x
versions of the R2DBC SPI. Currently, Spring only supports drivers
that implement the 0.8.x versions of the SPI.
https://github.com/oracle/oracle-r2dbc
DO NOT USE 0.2.0 with Spring - even worse than no error, queries just hang forever. I spent over a day trying to debug it. Not only I had the wrong version, but when I actually did try changing the version, my IDE was caching the old version out of sync with Maven.
After ensuring that all the libraries (only newer) seemed to exist on Wildfly 9, and checking the RestEasy migration page, I tried to deploy an app that works find on AS 7.1.1 (uses Resteasy 2.3.2) to WF9 (Resteasy 3.0.11) but it was unable to deploy due to this error:
Caused by: java.lang.NoClassDefFoundError: org/jboss/resteasy/core/ResourceMethod
Caused by: java.lang.ClassNotFoundException: org.jboss.resteasy.core.ResourceMethod from [Module \\\"deployment.CodecMapper.war:main\\\" from Service Module Loader]\"}}"
I jarfinded the class and looked in the catalog of resteasy-jaxrs-3.0.11-Final.jar but didn't find it (it was in the 2.3.2 version). Is it in a new jar or failed dependency? Or is this a migration issue I'll need to address in my code (even though it's not listed as one on the Resteasy migration page)?
I have also reviewed the Wildfly migration page specific to Resteasy, but I don't see any changes required.
I am using the latest Spring framework 4.1.5 and Hibernate-Entity-Manager 4.3.8 along with Javax.Persistence-api 1.0.2 all with JPA 2.1. This spec relies on Java EE 7. I noticed that in Resin 4.0.42, it uses "javaee-16.jar". The issue is I am getting the following exception:
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()
[Ljavax/persistence/Index;
at
org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:973)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3845)
Method javax.persistence.Table.indexes() only exists in Java EE 7
(Javax.Persistence-api 1.0.2) as a JPA 2.1 spec and NOT in Java EE 6 as a
JPA 2.0 spec.
Problem is my code is based on JPA 2.1. Is there anyway I can classload
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
even after Resin has classloaded: javaee-16.jar first?
Got it working where I load child libs first, not the other way around. Resin was loading Parent-first. I noticed others were having the same challenge with implementing JPA 2.1 on an app server that only implements JPA 2.0. The key is that each app server has their own specific way to configure child libs (or your app's libs) first.
In my case, in Resin.xml, add the following:
<class-loader>
<servlet-hack/>
</class-loader>
I has a similar error due to resin has jpa 2.0 and the app want jpa 2.1
fixed by added the lib to resin classpath in resin config file
<server-default>
<jvm-classpath>path/to/lib/hibernate-jpa-2.1-api-1.0.2.Final.jar</jvm-classpath>
....
<server-default>
Issue while Validating StAXSource in JBoss Server,
What I Tried:
I try to do parsing and validation at a time using StAX.
As described in this example.
I am able to execute the program as standalone application, but when I try it as a web application in JBoss EAP 6.1 server got below exception.
Exception:
java.lang.IllegalArgumentException: Source parameter of type
javax.xml.transform.stax.StAXSource' is not accepted by this validator.
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(Unknown Source)
There are multiple frame works modified from StAXSource to StreamSource,
TEIID-2046, activiti..etc.
I am not sure, Why JBoss is not supporting StAXSource, any clues?
Issue got resolved by adding xercesImpl 2.11.0 dependency. (as mentioned in forums_activiti)
Solution: add xerces 2.11.0 dependency.
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>
Details:
JBoss EAP 6.1 has Xerces 2.9.1-redhat-4, but StaxSource enhancement released in Xerces-J 2.10.0 (For more details refer JBoss EAP Component details).
Xerces-J 2.10.0 has implementation enhancement for java.xml.validation and supporting StAXSource for JAXP validator.
Update: Added Feature Request in JBoss EAP 1.6 project.
References:
http://comments.gmane.org/gmane.comp.apache.commons.general/1770
http://xerces.apache.org/xerces2-j/
http://people.apache.org/~edwingo/jaxp-faq.html
I'm trying to make new icefaces project which generated using: ICEfaces 3.3.0 project integration for Eclipse.
I didn't modify anything on the project. but when i try to run on the server, i got an error:
cannot Deploy MyProject
Deployment Error for module: MyProject:
Exception while loading the app : java.lang.Exception:
java.lang.IllegalStateException: ContainerBase.addChild:
start: org.apache.catalina.LifecycleException:
java.lang.NoSuchFieldError: SKIP_ITERATION
before that, I'm using ICEfaces 3.2.0 project integration for Eclipse and no problem.
I'm using Eclipse Indigo, GlassFish server 3, Mojarra 2.1.6
Thanks before
java.lang.NoSuchFieldError: SKIP_ITERATION
As per the javadoc, that field was added in JSF 2.1.
So, this error suggests that your webapp's runtime classpath is polluted with a JSF 2.0 API JAR file. Perhaps in the /WEB-INF/lib? Get rid of it. Glassfish already ships with JSF bundled, you don't necessarily need to supply your own. Or, from the other side on, this can also happen if you deploy to an ancient Glassfish instance which bundles JSF 2.0 and JSF 2.1 was actually bundled in your webapp in an attempt to upgrade it. If so, then you should edited the Glassfish config file sun-web.xml or glassfish-web.xml, depending on GF version. See for detail the answer to this related question: How to update Mojarra version in GlassFish