jbpm as rule engine and ProcessCalssLoader

[elis]

jBPM now is not fully ready to go as workflow engine, but it is perfect as ?rule engine?. Java codes also a process so graphical representation is very convenient. I wrote a small ProcessLauncher and all work well. I have only one small problem. I work with JBoss and want to put jbpm.jar to server lib folder (nor into .ear file). But ProcessClassLoader doesn?t ?see? my actions. I looked to the code and found next (ClassLoaderUtil.class):

public static ClassLoader getProcessClassLoader(ProcessDefinition processDefinition) {
return new ProcessClassLoader(ClassLoaderUtil.class.getClassLoader(), processDefinition);
}

May be better to replace this part by:

public static ClassLoader getProcessClassLoader(ProcessDefinition processDefinition) {
return new ProcessClassLoader(Thread.currentThread().getContextClassLoader(),processDefinition)
}

In this case we can put jbpm.jar into the server folder.

[kukeltje]

"elis" wrote:
jBPM now is not fully ready to go as workflow engine, but it is perfect as ?rule engine?.

Huh???? JBoss Rules (former Drools) is a perfect rules engine. JBoss jBPM is a perfect workflow engine (wel at least as perfect as big license based workflow engines)

What do you mis in jBPM that is in other engines to come to the conclusion that it is not perfect.

[elis]

I didn?t tell that other (rule engine) is worse. And I didn?t tell that jBPM. is not good as a workflow engine. I told only that right now jBPM is not fully ready (it is my opinion). jBPM has the perfect architecture. So, I think it will be in future the most useful workflow engine.
My question was only about ClassLoader strategy. Other is only my opinion.

[kukeltje]

Opinons are great, but I always like to hear the reasoning behind it ;-) The reason I asked is because jBPM was(is) not developed as a rule engine but as a wfe. Things that are perfect (according to others, in this case you) at what they were not intended for and not perfect at what the were intended for intrigue me

The classloaderUtil is becaus jBPM has the ability to store classes with processes in the database so they are versioned. That is why this code is like it is

[elis]

But I think my proposition about ClassLoader is not related how we use jBPM (in proper way or noJ). This is only about place where need to put jbpm.jar if we using web server. I read forum messages and saw the same problems with ProcessClassLoader. If we will use context class loader as a parent class loader it allow us to put this library not only to XXX.ear or to the lib folder of XXX.war. We can put this file directly to the lib server directory. It is not good solution for life but it is convenient in development phase.
Thanks for the answer.

[kukeltje]

you seem to be right, I mixed up two things.

It would be better then to implement the things in the comment in the ClassLoaderUtil getClassloader method:

// if this is made configurable, make sure it's done with the
 // jvm system properties
 // System.getProperty("jbpm.classloader")
 // - 'jbpm'
 // - 'context'
 //
 // or something like Thread.currentThread().getContextClassLoader();

That way it is configurable.

[elis]

It will be great. But in this case need to change
retrun new ProcessClassLoader(ClassLoaderUtil.class.getClassLoader(), processDefinition); to:
retrun new ProcessClassLoader(getClassLoader(), processDefinition);