Sadly I can't really help you, but maybe you can help me.
How did you successfully undeploy the predeployed jbpm.sar from the starters-kit? When I call
it says BUILD SUCCESS, but the jbpm.sar is still there.
I posted my problem here:
Thanks for any help
In all honesty, I knew I wouldn't be deploying the starter's kit in production, so I took the time to figure out all dependencies to do the following:
1) Use Maven for all my builds.
2) Deploy to standard JBoss 4.0.4
3) Build a custom SAR, rather than use the existing jbpm.sar. I wanted to add to the jBPM database schema, which required adding more hibernate mappings, so I needed these added to the hibernate.cfg.xml file, which resides in the jbpm.sar.
It was a bit of a pain, but worth the effort.
That's what I do to. So it is the right way ;-)
Thanks for the reply. Hey, what's the chances of getting jBPM releases up on ibiblio/maven2 with poms that hold all dependencies?
Also, here's another side question that's more about archive classloading than anything (working on multiple appservers, sometimes get wires crossed). I had a JAR library I developed, my custom SAR, and a webapp (WAR) I developed, all of which I put inside an EAR. All of the dependencies (JAR files) pulled in nicely to the EAR root, which alleviates the need to figure out each JAR to put into the server//lib directory. I gunned up JBoss, only to discover that even though all of my dependencies sat in the EAR root, the SAR and the WAR in my EAR were suffering ClassNotFoundExceptions, because they apparently these JARs in the EAR weren't on the classpath. Does this sound right? As I recall, an EAR was supposed to have its own ClassLoader and the contained SAR and WAR ClassLoaders were supposed to delegate to the EAR ClassLoader if a class could not be found. What am I missing?
Sorry -- I know these aren't jBPM questions per se, but they seemed analog to the thread.
JBoss has a (maven?) repository. Yes, their own, but it's just to have a little more control. See repository.jboss.com
jbpm is in there, only not with a pom which holds all dependencies. There is a difference in the libs required for building and running (at least lots of differences per application server). I'll pass it on to see how others react. The list of required libs is in the docs. Did you miss some there? If so, let us know or better yet, file a Jira issue.
Regarding the classloading (you threadjacker, oh sorry, it is your thread :-)) it could be a jbpm thing or not. Could you in a little more detail describe the structure and names of jars/sars/wars, what they supposed to do and from what class in what file you were trying to call another class and which one.
Well, my SAR and WAR just call classes in the jbpm.jar file and its depedent jars. My SAR isn't much different than the stock jbpm.sar from the starter's kit, it just has some of my additions. The only thing contained in my SAR file though is my configuration files. Similar situation in my WAR. It doesn't contain dependent JARs either. Both the SAR and WAR sit inside an EAR, and the ear contains all dependencies (JARs) at the EAR root level. The goal of this is twofold:
1) I don't have to manually muck with and maintain depedencies (JARs) in the server//lib directory, which complicates deployment to different JBoss instances.
2) The entire deployment of my SAR, WAR, and all dependent jars is self-contained inside a single EAR file. So to deploy all of this functionality, all I have to do is drop this EAR in the deploy directory of a vanilla JBoss installation.
So basically, those depdencies that sit at the EAR's root somehow are not getting seen by the SAR and the WAR. Hmmm......
The things that could be important are:
- is the jbpm jar outside your war/ear
- is the problem that jbpm cannot find classes in a war or jar in the ear?
It could be that the jBPM processclassloader is the culprit. It it is sometimes to restrictive. There is a jira issue to be able to configure jbpm to use the context classloader as it's parent. So therefor the question of where the jBPM jar is (in the sar?). If it is outside the ear, it is obvious it cannot access classes in the ear/war/jar. J2EE does not allow this (although you can configure JBoss AS to support this)