JBoss.orgCommunity Documentation
jPDL is an embeddable BPM engine, which means that you can take the jPDL libraries and embed it into your own Java project, rather then installing a separate product and integrate with it. One of the key aspects that make this possible is minimizing the dependencies. This chapter discusses the jbpm libraries and their dependencies.
lib/jbpm-jpdl.jar is the library with the core jpdl functionality.
lib/jbpm-identity.jar is the (optional) library containing an identity component as described in Section 11.11, “ The Identity Component ”.
All the libraries on which jPDL might have a dependency, are located in the lib directory. The actual version of those libraries might depend on the JBoss server that you've selected in the installer.
In a minimal deployment, you can create and run processes with jBPM by putting only the commons-logging and dom4j library in your classpath. Beware that persisting processes to a database is not supported. The dom4j library can be removed if you don't use the process xml parsing, but instead build your object graph programatically.
Table 4.1. Properties
| Library | Usage | Description |
|---|---|---|
| commons-logging.jar | logging in jbpm and hibernate | The jBPM code logs to commons logging. The commons logging library can be configured to dispatch the logs to e.g. java 1.4 logging, log4j, ... See the apache commons user guide for more information on how to configure commons logging. if you're used to log4j, the easiest way is to put the log4j lib and a log4j.properties in the classpath. commons logging will automatically detect this and use that configuration. |
| dom4j.jar | process definitions and hibernate persistence | xml parsing |
A typical deployment for jBPM will include persistent storage of process definitions and process executions. In that case, jBPM does not have any dependencies outside hibernate and its dependent libraries.
Of course, hibernate's required libraries depend on the environment and what features you use. For details refer to the hibernate documentation. The next table gives an indication for a plain standalone POJO development environment.
Table 4.2. Typical Dependencies
| Library | Usage | Description |
|---|---|---|
| hibernate.jar | hibernate persistence | the best O/R mapper |
| antlr.jar | used in query parsing by hibernate persistence | parser library |
| cglib.jar | hibernate persistence | reflection library used for hibernate proxies |
| commons-collections.jar | hibernate persistence | |
| asm.jar | hibernate persistence | asm byte code library |
The beanshell library is optional. If you don't include it, you won't be able to use the beanshell integration in the jBPM process language and you'll get a log message saying that jbpm couldn't load the Script class and hence, the script element won't be available.
Table 4.3. Optional Dependencies
| Library | Usage | Description |
|---|---|---|
| bsh.jar | beanshell script interpreter | Only used in the script's and decision's. When you don't use
these process elements, the beanshell lib can be removed, but then you
have to comment out the Script.hbm.xml mapping line in the
hibernate.cfg.xml |
The installer deploys jBPM into JBoss. This section walks you through the deployed components.
When jBPM is installed on a server configuration in JBoss, only the jbpm directory is added to the deploy directory and all components will be deployed under that directory. No other files of JBoss are changed or added outside that directory.
The enterprise bundle is a J2EE web application that contains the jBPM enterprise beans
and the JSF based console. The enterprise beans are located in
\deploy\jbpm\jbpm-enterprise-bundle.ear\jbpm-enterprise-beans.jar and the
JSF web application is located at
\deploy\jbpm\jbpm-enterprise-bundle.ear\jsf-console.war
If you want to see debug logs in the suite server, update file
jboss-{version}/server/default/config/log4j.xml
Look for
<!-- ============================== -->
<!-- Append messages to the console -->
<!-- ============================== -->
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="Target" value="System.out"/>
<param name="Threshold" value="INFO"/>
And in param Threshold, change INFO to
DEBUG.
Then you'll get debug logs of all the components. To limit the number of debug logs, look a bit further down that file until you see 'Limit categories'. You might want to add tresholds there for specific packages like e.g.
<category name="org.hibernate">
<priority value="INFO"/>
</category>
<category name="org.jboss">
<priority value="INFO"/>
</category>
First of all, in case you're just starting to develop a new process, it is much easier to use plain JUnit tests and run the process in memory like explained in Chapter 3, Tutorial .
But if you want to run the process in the console and debug it there here are the 2 steps that you need to do:
1) in
jboss-{version}/server/bin/run.bat, somewhere at the end,
there is a line like this:
rem set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y %JAVA_OPTS%
For backup reasons, just start by making a copy of that line, then remove the first 'rem'
and change suspend=y to suspend=n. Then you get something like
rem set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y %JAVA_OPTS% set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n %JAVA_OPTS%
2) In your IDE debug by connecting to a remote Java application on localhost on port 8787. Then you can start adding break points and run through the processes with the console until the breakpoint is hit.
For more info about configuring logging of optimistic locking failures, see Section 5.4, “ Logging Optimistic Concurrency Exceptions ”