0

I am including JBPM5.2 into my existing project. I have noticed some of the jar files are duplicated. below is the list 

                        my      jbpm
activation-1.1.jar  1.1 1.1
antlr-2.7.7.jar         2.7.7   2.7.7
Common-collections  2.1 3.1
common-io           1.1 1.4
dom4j-1.6.1.jar         1.6.1   1.6.1
Jdom-1.0.jar            1.0 1.0
Jta.jar                 1.0 1.1
Log4j                   1.2.15  1.2.14
Mail.jar            1.4 1.4

I am not keen to upgrade those jar because that means I have to do thorough regression test on my existing functions which is a lot. Basically i am looking for a safe and easy way.

I believe this is a very common issue that many people encounter. Can someone share with me his/her approach in getting this over.

Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
Zeliang
  • 1

2 Answers2

0

Few options I can think of

  1. If your unit of deployment is EAR (I am not sure if this is applicable for your app thought). Since the WAR can have its own classloader you can localize the jars to webapp. Go through this post Java EE class loading standard

  2. Another possibility is to deploy JBPM as a separate application by itself.

  3. Upgrade jars (my preference): From what I can see commons-* are the only jars that are deferring that too in MINOR versions only. So you no need to worry about anything. A smoke test or simple functional tests is all what you might need.

Community
  • 1
  • 1
Aravind Yarram
  • 78,777
  • 46
  • 231
  • 327
0

So, what kind of a dependency does your app have on jbpm? Will jbpm and your jar be in the same JVM under the same class loader? If so, you have a problem. Upgrading is the only correct solution.

Typically, in something like a web application, for example Tomcat or Jetty, the libraries needed by the server is on server's classpath. Each web application being deployed has its own class loader. The libraries that you depend on is available on this class loader which does not pollute the container itself.

Pavan
  • 1,245
  • 7
  • 10