As this issue essentially prevents the use of the RenderManager in EAR deployments it should be fixed ASAP.

Here's an EAR running on jBoss 4.0.5 GA that can reproduce the problem.

(I don't know if i should've post in the forum instead)

it consist of a War and ejb-jar inside an EAR
From the TestPush/index.faces page you are able to click on a button to send a JMS message to a topic.

The message is then received from a MessageDrivenBean that delivers it to the BackingBean, in the backing bean a requestRender() is called. That's when the problem occurs.

I've included the TestPush sources if needed.

Thank you.

I was able to replicate the issue and then modified the test case to run across several different app servers. Surprising how much work is involved in setting up a simple EAR to run on various containers.

The problem is definitely related to classloading. If the context classloader of the thread that originates the server-side render request comes from outside the web application context (e.g. a JMS message, Web Service, etc), then it cannot find the valid and appropriate JSF artifacts that it needs to run the JSF lifecyle events - execute() and render().

One way to reliably get the correct classloader is for the PersistentFacesState to keep a reference to the context classloader of the thread that called its constructor. New threads created in the RenderManager's pool are then given a reference to this classloader as their own context classloader before the lifecycle methods are executed. That way, the rendering thread has access to the proper web application context. The original code was not setting a context classloader that was reliably in the proper context.

The change has been committed to both the 1.5 branch and the 1.6 trunk (revision 13460).

Resolving as Fixed for 1.6 DR #3 and 1.5.4.