I actually reviewed JBoss 3.2.8 to see what is in there. I deleted the jboss-hibernate.sar dir and started the server. Nothing got broken up, so I assume you can remove it if your applications do not depend on Hibernate2. Once you do this, you can throw in find class version clashes if you throw in Hibernate3.
The story does not end there, tough. The jBPM console uses a web.xml descriptor that adheres to Servlet 2.4. JBoss 3.x supports Servlet 2.3 only. You'd have to migrate the descriptor and be ready for the challenge.
Further, it does not make sense to develop new applications against old standards. You should probably set up a separate JBoss 4.x instance and deploy your new applications there. The advantage of this option vs. jBPM standalone is that you can leverage the enterprise features such as the web container, managed data sources, JMS, etc.
Hope this helps,
One more thing, BPEL depends on WSEE 1.1 and JMS 1.1. The two of them are only available in JBoss 4.x.
Even if you manage to make jBPM run in JBoss 3.x, you will definitely not be able to run BPEL.
Your response was very helpful. Thank you Alejandro.
and the webconsole uses JSF 1.2 with some backported java5 things to jdk1.4. Not sure if that all works on jboss 3.x
Once you do this, you can throw in find class version clashes if you throw in Hibernate3.
This should read "you will not encounter class version classes when you throw in Hibernate3".