In fact, I see that the example jboss configuration that comes with the jpdl-suite distribution is 4.0.4 and it works very well.
So it is inexact to say that the web console does not work on 4.0.5, it just does not work on *mine*. I still fail to see in what my 4.0.5 is different JSF-wise from the example distribution.
ok, here is the answer. JBoss 4.0.5 comes with a Tomcat deployment with JSF version 1.1
JBPM console uses version 1.2 and has the 1.2 jsf jars inside the war.
My particular way of deploying the jBPM is as a war inside a EAR. JBoss by default uses a shared classloader that does not isolate EAR classloading space and it looks like the war inside the ear did not have access to its WEB-INF/lib libraries in priority.
To make it short, I changed in $JBOSS_HOME/server/default/deploy/ear-deployer.xml :
and everything is fine now.
It look like the first thing somebody should do after installing JBoss is turn on that attribute, anyway.
if you use the jboss/jems installer, it asks you how you want to configure this..
The messages you are referencing from the log are in fact INFO messages, which are just incorrectly written to STDERR and then wrapped by the logging system to ERROR level. So nothing to bother really. Do you get any other errors that indicate the web console doesn't work?
Regarding isolation, instead of changing the class loader setting for the complete app server, you could do this on a per-application basis as well. In your case by setting it inside your *.ear/META-INF/jboss-appl.xml configuration. Have a look at http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration for a complete overview of this topic.
Hi, thanks for your concern. I had read the wiki page you mention, still I personally find that it is saner to enable isolation for the whole appserver than to have a particular deployment descriptor specifying so.
In fact I did eventually succeed in making the console work. The problem I identified is that my JBoss 4.0.5 zip came by default with no classpath isolation which caused Tomcat's jsf implementation(1.1) to be loaded first.
That is my understanding, anyway. It is true that even with a shared classloader, the war classloader should function in a special way, prioritizing the WEB-INF/lib jars.
Still, changing that options made things work for me which is kind of all that I want :)
Special note for people interested : the 3.2.0 web console works with 3.2.1 jBPM, you just need to change in web.xml the roles (they have been renamed).