Stop wildfly war from initializing mojarra - jsf

Whenever I deploy a war to wildfly 8 or 10 (in this case it's a jax-rs service), I see the following line
[javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 151) Initializing Mojarra 2.2.11-jbossorg-1 20150505-1501 for context
Since JSF is not used in the application, is there a way to stop mojarra from being initialized?

Add a jboss-deployment-structure.xml file to your WEB-INF folder to stop deployment for a single war
<jboss-deployment-structure>
<deployment>
<exclude-subsystems>
<subsystem name="jsf" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>

You can remove
<subsystem xmlns="urn:jboss:domain:jsf:1.0"/>
from your profile.
It should stop Mojarra initialization.

Related

Unable to obtain com.sun.faces.flow.FlowDiscoveryCDIExtension. Flows described with javax.faces.flow.builder.FlowDefinition are unavailable

21:39:39,453 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (Se
rverService Thread Pool -- 103) Unable to obtain com.sun.faces.flow.FlowDiscover
yCDIExtension from CDI implementation. Flows described with javax.faces.flow.bu
ilder.FlowDefinition are unavailable.
I'm using Jboss EAP 6.1, with CDI, Hibernate, and JSF 2.2. I thought it might be caused by JSF 2.2, so I changed the face-config.xml to 2.0, but the error still exist.
I followed this guide: https://developer.jboss.org/thread/203257
This is what my module looks like:
This is what my module.xml looks like:
<dependencies>
<module name="javax.faces.api"/>
<module name="javaee.api"/>
<module name="javax.servlet.jstl.api"/>
<module name="org.apache.xerces" services="import"/>
<module name="org.apache.xalan" services="import"/>
</dependencies>
<resources>
<resource-root path="jsf-impl-2.2.7.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="javax.el.api" export="true"/>
<module name="javax.servlet.api" export="true"/>
<module name="javax.servlet.jsp.api" export="true"/>
<module name="javax.servlet.jstl.api" export="true"/>
<module name="javax.validation.api" export="true"/>
<module name="com.sun.jsf-impl"/>
</dependencies>
<resources>
<resource-root path="jsf-api-2.2.7.jar"/>
<!-- Insert resources here -->
</resources>
How did you switch to JSF 2.2?
If you included jar files in your war/ear file then one of these is loading and trying to load a CDI extension but the jar containing that class is not available. Try removing any JSF jars from your deployment archive and see if it goes away.
If you added it to your server as a module you may have missed a jar file or dependent module that is part of the JSF module from the definition. Remove the changed or added module and see if it goes away.

EclipseLink 2.4 And JBOSS AS 7 project JPA EJB JSF

I'm trying to deploy and run a project with these particular technologies:
EJB3.1
Eclipse Link 2.4, JDBC 14.
Oracle 10g.
SJBOSS 7.
Java EE 6
I have been trying to make a Hello World example since 4 days and i don't have it runnning yet, right now i'm stuck with some weired erros.
This is what i have done until now:
We created the Eclipse Link module in Jboss
So i created the module in Jboss so i can access oracle Database:
<module xmlns="urn:jboss:module:1.0" name="org.eclipse.persistence">
<resources>
<resource-root path="eclipselink.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.persistence.api"/>
<module name="javax.transaction.api"/>
<module name="javax.validation.api"/>
<module name="javax.xml.bind.api"/>
<module name="org.antlr"/>
<module name="org.apache.commons.collections"/>
<module name="org.dom4j"/>
<module name="org.javassist"/>
<module name="org.jboss.logging"/>
<module name="com.oracle.ojdbc14"/>
</dependencies>
</module>
After that i created the module for the oracle database in the xml file
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.oracle.ojdbc14">
<resources>
<resource-root path="ojdbc14.jar"/>
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
finally i changed the Standalone.xml, this is the part of the standalone that i changed:
<subsystem xmlns="urn:jboss:domain:datasources:1.0">
<datasources>
<datasource jndi-name="java:/EclipseLinkDS" pool-name="EclipseLinkDS" enabled="true" jta="true" use-java-context="true" use-ccm="true">
<connection-url>
jdbc:oracle:thin:localhost:1521:TOPLINK
</connection-url>
<driver>
oracle
</driver>
<transaction-isolation>
TRANSACTION_READ_COMMITTED
</transaction-isolation>
<pool>
<prefill>
true
</prefill>
<use-strict-min>
false
</use-strict-min>
<flush-strategy>
FailingConnectionOnly
</flush-strategy>
</pool>
<security>
<user-name>
codesa
</user-name>
<password>
codesa
</password>
</security>
</datasource>
<drivers>
<driver name="oracle" module="com.oracle.ojdbc14">
<driver-class>
oracle.jdbc.driver.OracleDriver
</driver-class>
<xa-datasource-class>
oracle.jdbc.xa.client.OracleXADataSource
</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
When i run the EJB PROJECT on eclipse i get the following erros:
16:19:29,204 INFO [org.jboss.jpa] (MSC service thread 1-2) read persistence.xml for em
16:19:29,333 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named CategoriaBase in deployment unit subdeployment "p.jar" of deployment "p_ear.ear" are as follows:
java:global/p_ear/p/CategoriaBase!base.CategoriaBaseRemote
java:app/p/CategoriaBase!base.CategoriaBaseRemote
java:module/CategoriaBase!base.CategoriaBaseRemote
java:global/p_ear/p/CategoriaBase!base.CategoriaBaseLocal
java:app/p/CategoriaBase!base.CategoriaBaseLocal
java:module/CategoriaBase!base.CategoriaBaseLocal
16:19:29,333 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named CategoriaBackingBean in deployment unit subdeployment "p_web.war" of deployment "p_ear.ear" are as follows:
java:global/p_ear/p_web/CategoriaBackingBean!backingbeans.CategoriaBackingBean
java:app/p_web/CategoriaBackingBean!backingbeans.CategoriaBackingBean
java:module/CategoriaBackingBean!backingbeans.CategoriaBackingBean
java:global/p_ear/p_web/CategoriaBackingBean
java:app/p_web/CategoriaBackingBean
java:module/CategoriaBackingBean
16:19:29,398 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.subunit."p_ear.ear"."p.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."p_ear.ear"."p.jar".INSTALL: Failed to process phase INSTALL of subdeployment "p.jar" of deployment "p_ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_43]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_43]
at java.lang.Thread.run(Unknown Source) [:1.6.0_43]
Caused by: java.lang.NullPointerException
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.addProviderProperties(PersistenceUnitDeploymentProcessor.java:346)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.addPuService(PersistenceUnitDeploymentProcessor.java:253)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.handleJarDeployment(PersistenceUnitDeploymentProcessor.java:115)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deploy(PersistenceUnitDeploymentProcessor.java:96)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
... 5 more
16:19:29,630 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployment of "p_ear.ear" was rolled back with failure message {"Failed services" => {"jboss.deployment.subunit.\"p_ear.ear\".\"p.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"p_ear.ear\".\"p.jar\".INSTALL: Failed to process phase INSTALL of subdeployment \"p.jar\" of deployment \"p_ear.ear\""},"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".component.CategoriaBackingBean.START missing [ jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\" ]","jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".jndiDependencyService missing [ jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\" ]","jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\".jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".module.p_ear.p_web.2 missing [ jboss.deployment.subunit.\"p_ear.ear\".\"p.jar\".component.CategoriaBase.VIEW.\"base.CategoriaBaseRemote\".REMOTE ]","jboss.naming.context.java.comp.p_ear.p.CategoriaBase.ValidatorFactory missing [ jboss.naming.context.java.comp.p_ear.p.CategoriaBase ]","jboss.naming.context.java.comp.p_ear.p.CategoriaBase.Validator missing [ jboss.naming.context.java.comp.p_ear.p.CategoriaBase ]","jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".component.\"backingbeans.CategoriaBackingBean\".START missing [ jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\" ]"]}
16:19:29,642 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) Stopped deployment p.jar in 12ms
16:19:29,651 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment p_web.war in 21ms
16:19:29,653 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment p_ear.ear in 24ms
16:19:29,655 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 1) {"Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"Failed services" => {"jboss.deployment.subunit.\"p_ear.ear\".\"p.jar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"p_ear.ear\".\"p.jar\".INSTALL: Failed to process phase INSTALL of subdeployment \"p.jar\" of deployment \"p_ear.ear\""},"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".component.CategoriaBackingBean.START missing [ jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\" ]","jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".jndiDependencyService missing [ jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\" ]","jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\".jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".module.p_ear.p_web.2 missing [ jboss.deployment.subunit.\"p_ear.ear\".\"p.jar\".component.CategoriaBase.VIEW.\"base.CategoriaBaseRemote\".REMOTE ]","jboss.naming.context.java.comp.p_ear.p.CategoriaBase.ValidatorFactory missing [ jboss.naming.context.java.comp.p_ear.p.CategoriaBase ]","jboss.naming.context.java.comp.p_ear.p.CategoriaBase.Validator missing [ jboss.naming.context.java.comp.p_ear.p.CategoriaBase ]","jboss.deployment.subunit.\"p_ear.ear\".\"p_web.war\".component.\"backingbeans.CategoriaBackingBean\".START missing [ jboss.naming.context.java.module.p_ear.p_web.\"env/backingbeans.CategoriaBackingBean/categoriaBean\" ]"]}}}
Anyone know how can i fix it ? I just need to make a good conexion in order to be able to develop the full app running.
If you got a tip or something, will be pretty appreciated.

Using Hibernate 4.0.1 in JBoss 6.0

I have to use version 4.0.1 of Hibernate in my enterprise application. The EAR is deployed into a JBoss 6.0 Container.
The ear file contains the following hibernate jars:
hibernate-commons-annotations-4.0.1.Final.jar
hibernate-core-4.0.1.Final.jar
hibernate-entitymanager-4.0.1.Final.jar
hibernate-envers-4.0.1.Final.jar
hibernate-envers-4.0.1.Final.jar
hibernate-envers-4.0.1.Final.jar
hibernate-search-analyzers-4.0.0.Final.jar
hibernate-search-engine-4.0.0.Final.jar
hibernate-search-engine-4.0.0.Final.jar
hibernate-validator-4.2.0.Final.jar
According to Upgrade Hibernate version in JBOSS I've tried to configure custom classloading using the follwing jboss-app.xml and jboss-classloading.xml
<!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_5_0.dtd">
<jboss-app>
<loader-repository>
com.acme.sample:archive=Sample
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</jboss-app>
<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
domain="sample.ear"
export-all="NON_EMPTY"
import-all="true"
parent-first="false">
</classloading>
When starting up the JBoss 6 Container following lines occur in the log file:
09:49:55,238 INFO [org.hibernate.annotations.common.Version] HCANN000001: Hibernate Commons Annotations {4.0.1.Final}
09:49:55,265 INFO [org.hibernate.Version] HHH000412: Hibernate Core {4.0.1.Final}
Seems as if Hibernate 4.0.1 has been detected. But then the following exception occurs:
09:49:55,388 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=persistence.unit:unitName=sample-SNAPSHOT.ear/lib/persistence_impl-0.0.21-SNAPSHOT.jar#sample state=Create: java.lang.ClassCastException: org.jboss.as.jpa.scanner.HackTLScanner cannot be cast to org.hibernate.ejb.packaging.Scanner
at org.hibernate.ejb.Ejb3Configuration.buildScanner(Ejb3Configuration.java:415) [:3.6.0.Final]
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:582) [:3.6.0.Final]
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:72) [:3.6.0.Final]
at org.jboss.jpa.builder.DefaultCEMFBuilder.build(DefaultCEMFBuilder.java:47) [:1.0.2-alpha-3]
at org.jboss.as.jpa.scanner.HackCEMFBuilder.build(HackCEMFBuilder.java:49) [:6.0.0.Final]
at org.jboss.jpa.deployment.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:275) [:1.0.2-alpha-3]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.GA]
In the exception stack trace the version 3.6.0.Final of hibernate is mentioned. Seems as if the Container still tries to create the JPA Persistence Unit using the version of hibernate that ships with JBoss.
Can anybody give me a hint on what I am doing wrong and how to configure the custom classloading so that JBoss uses the Hibernate version that is packaged in the EAR file.
I have done a workaround for this problem and it works...
my ear structure is like this--->
accountEAR.ear
|
|--lib
|<all jars for hibernate 4.0.1 and mysql jdbc jar>
|
|--META-INF
| application.xml
| jboss-app.xml
| jboss-classloading.xml
| mysql-ds.xml
|
|-- account_persistence.jar
jboss version is 6.1 and mysql version 5.1
jboss-app.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD Java EE Application 5.0//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_5_0.dtd" >
<jboss-app>
<loader-repository>
com.accountEAR:loader=accountEAR
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
<library-directory>lib</library-directory>
</jboss-app>
jboss-classloading.xml:
<?xml version="1.0" encoding="UTF-8"?>
<classloading
xmlns="urn:jboss:classloading:1.0"
export-all="NON_EMPTY"
import-all="true"
parent-first="false"/>

MyFaces clash with GlassFish 3.1 native JSF

I'm using MyFaces with Trinidad. The following SEVERE message keeps coming on startup:
SEVERE: Both MyFaces and the RI are on your classpath.
Please make sure to use only one of the two JSF-implementations.
I have the following in my glassfish-web.xml:
<glassfish-web-app error-url="">
<class-loader delegate="false"/>
<property name="useMyFaces" value="true"/>
</glassfish-web-app>
And the following JARs in classpath:
antlr-2.7.6.jar* hibernate3.jar*
cglib-2.2.2.jar javassist-3.9.0.GA.jar*
commons-beanutils-1.8.3.jar jta-1.1.jar*
commons-collections-3.1.jar* junit-4.9.jar
commons-collections-3.2.jar myfaces-api-2.1.2.jar
commons-digester-1.8.jar myfaces-commons-utils20-1.0.1.jar
commons-digester3-3.0.jar myfaces-components20-1.0.1.jar
commons-logging-1.1.1.jar myfaces-converters20-1.0.1.jar
commons-validator-1.3.1.jar myfaces-impl-2.1.2.jar
cssparser-0.9.5.jar myfaces-validators20-1.0.1.jar
dom4j-1.6.1.jar* mysql-connector-java-5.0.8-bin.jar
ejb3-persistence.jar* slf4j-api-1.5.10.jar*
hibernate-annotations.jar* slf4j-ext-1.5.10.jar*
hibernate-commons-annotations.jar* slf4j-simple-1.5.10.jar*
hibernate-entitymanager.jar trinidad-api-2.0.0.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar trinidad-build-2.0.0-sources.jar
hibernate-validator-4.2.0.Final.jar trinidad-impl-2.0.0.jar
I'm not quite sure how to eliminate the SEVERE message based on the configuration I've already done, any thoughts would be appreciated!

Exception: could not find Factory: javax.faces.context.FacesContextFactory

I'm migrating from JBoss 5.1.0.GA to JBoss 6.0.0-Final and facing following exception during FacesServler initialization
2011-03-09 18:07:24,574 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/].[Faces Servlet]] (http-0.0.0.0-8080-4) Allocate exception for servlet Faces Servlet: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:725) [:1.2_15-20100816-SNAPSHOT]
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239) [:1.2_15-20100816-SNAPSHOT]
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164) [:1.2_15-20100816-SNAPSHOT]
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) [:6.0.0.Final]
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:955) [:6.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) [:6.0.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_14]
I've looked into code and found out that FactoryFinder looks up corresponding FactoryManager based on current thread classloader. I also found that my FactoryFinder.FACTORIES_CACHE contains two entries for two class loaders:
* BaseClassLoader which loads my EAR and
* WebCtxLoader.ENCLoader which is used during web app running and which was current context classloaded for failed thread.
My deploy structure is following:
* deploy
o myapplication.ear
+ lib
# richfaces jars (3.3.1.GA)
# seam jars (2.2.1.Final)
# openfaces jar (2.0.0)
# other jars
+ META-INF
# jboss-app.xml
# application.xml
+ myapplication.war
# WEB-INF
* web.xml
* faces-config.xml
* components.xml
* deployers
o jbossweb.deployer
o jsf.deployer
o and others
I'm using Mojarra-1.2 as JSF implementation
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>Mojarra-1.2</param-value>
After some debugging I could sumup:
1. all JSF initialization is made in BaseClassLoader thread, i.e. when javax.faces.FactoryFinder#setFactory(..) is invoked getClassLoader() returns EAR BaseClassLoader
2. A servlet thread (which cause exception) tries to look FactoryManager but his current classloader ( Thread.currentThread().getContextClassLoader()) is WebCtxLoader.ENCLoader. So nothing is returned and exception is thrown.
I checked JBoss 5.1.0 and ensured that initialization and access for FactoryManager's were made in threads having same class loader.
I've tried to google by didn't find much information about anybody having same problem - which makes me think something is wrong in my environment.
Can anybody comment on or help with this?
This is a sign of classpath pollution. JBoss already ships with JSF bundled. This exception can occur if you bundle JSF in your WAR as well. It'll only collide.
There are 2 solutions:
Get rid of jsf-api and jsf-impl JARs in your WAR (i.e. they should not end up in /WEB-INF/lib after build/deploy.
Tell JBoss that your WAR ships with its own version of JSF so that JBoss won't use its own.
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
I had the same issue, but with embedded GlassFish v3. I added this and it worked:
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
Here is the web page explains the problem: Using JSF 1.2 with Facelets on Google App Engine.
I was having the same problem with Jboss EAP 6.1 and 6.3.
I´m using Maven, then, my problem was about the generation of the EAR file, when I´m using Maven I discovered that my EAR file was been deployed whith dependencies "exploded", that is to say, my EAR file was been deployed with a folder containing the files for my project, and not a WAR and a JAR files.
When investigating the differences between the exploded EAR directory and the EAR archive I discovered that what you see is not what you get with Maven. I think the issue is that the various Maven plugins for WAR and EAR building are not applied when creating the exploded directories.
To fix it, I just removed the 'unpack' directives from the POM for the EAR.
<modules>
<webModule>
<groupId>br.web</groupId>
<artifactId>Web</artifactId>
<contextRoot>/project</contextRoot>
<unpack>false</unpack>
</webModule>
<ejbModule>
<groupId>br.ejb</groupId>
<artifactId>Ejb</artifactId>
<unpack>false</unpack>
</ejbModule>
</modules>
In addition, I don't recommend that exploded directories should be used in a EAR file.

Resources