[10/20/21 15:20:38:248 GMT] 0000006e view E Unable to obtain CDI 1.1 utilities for Mojarra
[10/20/21 15:20:38:254 GMT] 0000006e flow E Unable to obtain CDI 1.1 utilities for Mojarra
Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger
at java.net.URLClassLoader.findClass(URLClassLoader.java:610)
at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:244)
at com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:129)
at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:62)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:58)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:607)
at java.lang.ClassLoader.loadClass(ClassLoader.java:872)
One problem here is that WebSphere 9 does not provide CDI integration with third-party JSF implementations like Mojarra. I'm not sure if this message Unable to obtain CDI 1.1 utilities for Mojarra error is caused by that lack of integration. IBM provides some docs for configuring third-party JSF implementations - for example putting the Mojarra lib in an isolated shared library is recommended.
Regardless CDI ViewScoped beans will not work correctly in this configuration. The WebSphere 9 runtime provides JSF MyFaces 2.2, which does have CDI integration. If you do need CDI+JSF integration, you should consider updating your app to use the JSF provided by WebSphere 9.
Related
I am trying to configure my ESB server as a client for JBoss EAP 7.1 integrated Active MQ Artemis which will connect using the RemoteConnectionFactory. However, I couldn't use the JBoss client jar as it conflicts with the internal JARs. Therefore, I added all the necessary JARs separately.
Now an exception is being thrown saying no provider found.
I have added both xnio-api and xnio-nio jars.
Below is the exception.
Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
at org.xnio.Xnio.doGetInstance(Xnio.java:226)
at org.xnio.Xnio.getInstance(Xnio.java:192)
at org.jboss.naming.remote.client.EndpointCache.get(EndpointCache.java:47)
at org.jboss.naming.remote.client.InitialContextFactory.createEndpoint(InitialContextFactory.java:226)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateEndpoint(InitialContextFactory.java:207)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateNamingStore(InitialContextFactory.java:170)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:146)
... 50 more
How do I resolve this error?
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 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.
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
Having deployed an EJB module in JBoss 7.0.1, I am trying to access it from a client executing on another JVM. However, I am unable to figure out the client side jars needed to add to my client's classpath.
I tried out with the following:-
jboss-ejb-api_3.1_spec-1.0.1.Final.jar
jboss-ejb-client-1.0.0.Beta11.jar
3.jboss-logging-3.1.0.CR2.jar
jboss-marshalling-1.3.4.GA.jar
5.jboss-marshalling-river-1.3.4.GA.jar
jboss-remoting-3.2.0.CR8.jar
7.jboss-sasl-1.0.0.Beta9.jar
jboss-transaction-api_1.1_spec-1.0.0.Final.jar
xnio-api-3.0.0.CR7.jar
There seems to be some inconsistency in this setup and I get this exception:-
INFO: JBoss EJB Client version 1.0.0.Beta11 Nov 9, 2012 12:01:04 AM
org.xnio.Xnio INFO: XNIO Version 3.0.0.CR7 Nov 9, 2012
12:01:04 AM org.jboss.ejb.client.ConfigBasedEJBClientContextSelector
createConnections ERROR: Could not create connection for connection
named default java.lang.IllegalArgumentException: No matching XNIO
provider found at org.xnio.Xnio.doGetInstance(Xnio.java:192) at
org.xnio.Xnio.getInstance(Xnio.java:146) at
org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
...
I didn't have any issues while having a client access an ejb deployed in JBoss 7.1.0 Final, JBoss 6.1.0 Final or Glassfish servers. The jars required at the client side war available.
I am a newbie in Java EE and Application Servers by the way and I am trying to learn in the process.
Thanks.
please add xnio-nio-3.0.3.GA.jar in your classpath
In addition to Ramkumar's answer, I am adding the maven dependency for this jar. Following the maven dependency for the jar:
<dependency>
<groupId>org.jboss.xnio</groupId>
<artifactId>xnio-nio</artifactId>
<version>3.0.3.GA</version>
</dependency>