[pgarner]

Whoops!  Yes, I removed company-specific information.

[pgarner]

Oh my gosh no.  Sorry if it came across that way.  I sincerely thought that Stephen Coy was referring to some means by which we could escalate the issue by perhaps clicking on a link in the page that would "flag" it somehow to get the attention of the developers.  I did not know how to go about doing that.  I apologize if I've offended anybody.

[jaikiran]

Patrick Garner wrote:

Whoops!  Yes, I removed company-specific information.

Okay so that rules out the obvious issues. Which now leaves us with the following questions:

1) Why is the persistence processing picking up ViewExpiredExceptionExceptionHandler class? Is it referenced in some entity classes? If so, how?

2) That class does reside in the module which the exception stacktrace is complaining about [Module "deployment.webapp.ear.webapp-ejb-1.0-SNAPSHOT.jar:main]. This shouldn't really be happening. The stacktrace also talks about the temp classloader:

Caused by: java.lang.RuntimeException: JBAS011431: Could not load entity class 'com.webapp.exception.ViewExpiredExceptionExceptionHandler' with PersistenceUnitInfo.getNewTempClassLoader()

I don't know much about the temp classloader and its usage. Scott would know more.

[pgarner]

Scott, I obtained jboss-as-7.1.0.Final-SNAPSHOT and am trying to test but I cannot figure out how to shut it down.  Usually I "$JBOSS_HOME/bin/jboss-admin.sh --connect command=:shutdown' but I do not see jboss-admin.sh in the bin directory, and I don't see any valid args that can be passed to standalone.sh in order to make jboss shutdown.

[pgarner@localhost jboss]$ find . -name *.sh

./bin/util/vault.sh

./bin/util/jdr.sh

./bin/domain.sh

./bin/standalone.sh

./bin/wsprovide.sh

./bin/jconsole.sh

./bin/add-user.sh

./bin/appclient.sh

./bin/jboss-cli.sh

./bin/wsconsume.sh

./bin/init.d/jboss-as-standalone.sh

[pgarner]

I removed ViewExpiredException and ViewExpiredExceptionHandlerFactory from the webapp in order to help debug the problem.  I did this earlier on in the process of debugging (see my post #5, above).  The exception and the factory were not referenced by any objects in my web app.  Rather, they were declared in the following config files:

web.xml:

<error-page>

    <exception-type>com.webapp.exception.ViewExpiredException</exception-type>

    <location>/faces/viewExpired.xhtml</location>

</error-page>

faces-config.xml:

<factory>

    <exception-handler-factory>com.webapp.exception.ViewExpiredExceptionExceptionHandlerFactory</exception-handler-factory>

</factory>

[pgarner]

Scott,  the problem still occurs in the nightly build, JBoss AS 7.1.0.Final-SNAPSHOT:

13:47:06,682 INFO  [org.jboss.modules] JBoss Modules version 1.1.0.GA

13:47:08,406 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA

13:47:08,969 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.0.Final-SNAPSHOT "Flux Capacitor" starting

...

13:49:00,507 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-1) WELD-000119 Not generating any bean definitions from com.patrac.util.Util because of underlying class loading error

13:49:00,517 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-1) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.patrac.util.Util

        at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]

        at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]

        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:1110) [rt.jar:1.7.0_02]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_02]

        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_02]

Caused by: java.lang.NoClassDefFoundError: javax/faces/event/ActionEvent

        at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.7.0_02]

        at java.lang.Class.privateGetDeclaredMethods(Class.java:2442) [rt.jar:1.7.0_02]

        at java.lang.Class.getDeclaredMethods(Class.java:1808) [rt.jar:1.7.0_02]

        at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:172) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:169) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:169) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:233) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        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) [weld-core-1.1.5.Final.jar:2012-01-06 11:59]

        ... 11 more

Caused by: java.lang.ClassNotFoundException: javax.faces.event.ActionEvent from [Module "deployment.Patrac.ear.Patrac-ejb-1.0-SNAPSHOT.jar:main" from Service Module Loader]

        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

        ... 29 more

It seems like when the web app is deployed as an EAR the classloader can't find the javax.faces.* packages.  When I comment out the following methods in my Util class the application deploys without errors:

	public static String getAttribute(ActionEvent event, String name)
	{
	return (String)event.getComponent().getAttributes().get(name);
	}

	public static String getRequestParameter(String name)
	{
	return (String) FacesContext.getCurrentInstance().getExternalContext()
	.getRequestParameterMap().get(name);
	}

If I attempt to deploy code that makes a reference to a FacesContext, ExternalContext, ActionEvent, etc. object in a managed bean or utility class I get a ClassNotFoundException.  This only happens when I deploy the webapp as an EAR.  If deploy as a war the exception is not thrown.

[smarlow]

The ViewExpiredExceptionExceptionHandlerc class extends javax.faces.context.ExceptionHandlerWrapper which might not be on the Webapp-ejb-1.0-SNAPSHOT.jar or Patrac-ejb-1.0-SNAPSHOT.jar  classpath.  It sounds like a dependency on javax.faces.api is not automatically set. 

A workaround might be to add a dependency on "javax.faces.api" (see https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7).

[pgarner]

Scott, when I add the "javax.faces.api" dependency the webapp deploys without throwing an exception.  Later, when I click on a commandLink that invokes a method that references javax.faces.* objects e.g. FacesContext, ExternalContext, ActionEvent, etc. a NullPointerException is thrown as shown here:  http://stackoverflow.com/questions/9136108/facescontext-getcurrentinstance-returns-null-within-request-handled-by-facesse

[smarlow]

I think the NPE means, we haven't changed enough yet but are definitely getting further.  I wonder if https://docs.jboss.org/author/display/AS71/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 might have ideas of what else needs to change.

[ssilvert]

I don't remember all the specifics of the JSF classloading in AS7, but I can tell you that JSF doesn't really belong in an EJB module.  JSF absolutely must run from inside the servlet container.  JSF relies on the servlet API.  So calling a JSF API from outside that servlet container can cause problems.  In particular, FacesContext.getCurrentInstance() relies on a ThreadLocal variable stored in the servlet's HttpRequest thread.  So if your EJB is not using that same thread it will fail.

I hate to give you a "Just don't do that" answer, but module boundries are there for a reason.  If you still want to do this you can probably muck around with the classloader settings of your EAR and also make sure that you are doing everything on the servlet request thread.  But it's sure a lot easier if you "Just don't do that".

Stan

[pgarner]

Stan, I have no reason to be calling a JSF API from within the EJB module other than "I didn't know I wasn't supposed to do that."  My adventure with EAR deployment began when I decided to migrate a web application from WAR deployment to EAR.  I began by using JBoss' maven archetype "org.jboss.spec.archetypes:jboss-javaee6-ear-webapp," which created this:

[pgarner@localhost Foo]$ tree

.

|-- Foo-ear

|   `-- pom.xml

|-- Foo-ejb

|   |-- pom.xml

|   `-- src

|       |-- main

|       |   |-- java

|       |   |   `-- com

|       |   |       `-- foo

|       |   |           |-- controller

|       |   |           |   `-- MemberRegistration.java

|       |   |           |-- data

|       |   |           |   `-- MemberListProducer.java

|       |   |           |-- model

|       |   |           |   `-- Member.java

|       |   |           `-- util

|       |   |               `-- Resources.java

|       |   `-- resources

|       |       |-- import.sql

|       |       `-- META-INF

|       |           |-- beans.xml

|       |           `-- persistence.xml

|       `-- test

|           |-- java

|           |   `-- com

|           |       `-- foo

|           |           `-- test

|           |               `-- MemberRegistrationTest.java

|           `-- resources

|-- Foo-web

|   |-- pom.xml

|   `-- src

|       `-- main

|           |-- java

|           |   `-- com

|           |       `-- foo

|           |           `-- rest

|           |               |-- JaxRsActivator.java

|           |               `-- MemberResourceRESTService.java

|           `-- webapp

|               |-- index.html

|               |-- index.xhtml

|               |-- resources

|               |   |-- css

|               |   |   `-- screen.css

|               |   `-- gfx

|               |       |-- banner.png

|               |       `-- logo.png

|               `-- WEB-INF

|                   |-- beans.xml

|                   |-- faces-config.xml

|                   `-- templates

|                       `-- default.xhtml

|-- pom.xml

`-- README.md

MemberRegistration is an EJB, MemberListProducer is a managed bean, Member is a JPA entity and Resources uses CDI to alias JEE resources for clients.  The EJB and managed bean both provide a means to access data in a facelet via EL variables.  Seeing this, I assumed that calling the JSF API from within the EJB module was fine.  Having taken a second look at the classes in the EJB module, I see that they don't use the JSF API.  This really makes sense to me now.

If I understand correctly, any managed beans, helper classes, etc. that need to use the JSF API will need to be placed in Foo-web/src/main/java, right?

Also, I notice that MemberResourceRESTService gets deployed inside the servlet container and that it is a CDI bean injected with the persistence context from the Resources class from inside the EJB container.  So, it's fine for my managed beans and such who are deployed in the servlet container to follow MemberResourceRESTService's example?

[sfcoy]

I should have spotted this earlier.

Table EE6.1 in the Java EE Spec, v6 clearly states which technologies are intended to be available from the EJB container.

And all of the servlet, JSP and JSF technologies are excluded.

The table is referenced from §EE.8.3.2 EJB Container Class Loading Requirements, which says:

Components in the EJB container must have access to the following classes and resources.
...
• The Java EE API classes specified in Table EE.6-1 for the EJB container.
...