3 Replies Latest reply on Sep 10, 2005 6:07 AM by Tom Baeyens

    Action classes and par deployment issues

    Dani Kenan Newbie

      I think there is something I do not fully understand regarding deployment of par files and action handler classes.

      The process archives (par) are deployed to the jbmp service. When a
      process is deployed, it can be used from many applications.

      If the above is correct then I would excpect the abilty to deploy also the action classes needed (plus dependencies) to the jbpm serice. Each such process needs to be fully functional by its own - like a small scale service.

      Otherwise, each application calling/using the proccess needs to know the internals of the process and include all it requires to run.

      Is there a way to include the code dependcies in the par, or am I getting it all wrong and it is not needed?

        • 1. Re: Action classes and par deployment issues
          Koen Aers Master

          The par file may or may not include the classes used as action handlers in the process definition. If they are included, they are versioned all along with the process definition, and client programs don't have to know about them. If they are not, they are not versioned and have to reside on the classpath of the client program.

          Regards,
          Koen

          • 2. Re: Action classes and par deployment issues
            Dani Kenan Newbie

            Thanks for your reply, however this is not what I asked about.

            I am familiar with the ability to include action classes in the par and the way they are versioned.

            However, if an action class depends on several third party libraries (jar files) I do not have a way to include them. The action classes worth nothing without the libraries they depend on. So all client need to have the depenedcies.

            Yes, I know that you may put the libraries in the server classpath or some "shared library" folder of some sort, in an application server. However, this polutes the environment and is not a robust solution. Version collisions and "jar hell" will show up for sure.

            A better way is to allow par files to include library files in a lib dir, extract it to a directroy with a name based on the par and version name and change the classloader par files to load that directory. If you have to use a db, this can be done to using a db also.

            We are now using jBPM in a POC. If that succeed, we will probably build some extension based on jBPM and replace the deployment all together to allow a par to include many processes as well as library files and replace the proccess classloader to use the libraries as well as cache the loaded classes (which will much improve the current jbpm classloader performance).

            Once we have this code, I will send it to jboss for inspection and if you find it good enough, for inclusion in the jBPM project.

            I

            • 3. Re: Action classes and par deployment issues
              Tom Baeyens Master

              hmmm... many processes and libraries in a process archive... seems an interesting idea. a few things to think about though:

              how does this impact on process versioning. will a redeploy of the master process archive lead to new process definition versions of all the processes ?

              for adding libraries to the process archives. why can't you create a ejb or a war to isolate the jbpm process libs from the other applications on your server ? that would be a solution inbetween using the server's global classpath and the inclusion of the libs in the process archive. if you don't need the classes versioned, i would definitely recommend to avoid putting classes in the process archives. they end up in the database and have to be loaded from the database. which is a bit more timeconsuming then from the file system.

              another thing is that we probably will have to rename the .par extension. now that the ejb3 comittee was so kindly to steal our perfectly chosen extension :-((((

              regards, tom.