Two Laptop Bag*
The moose likes EJB and other Java EE Technologies and the fly likes LOG4J Incompatability Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "LOG4J Incompatability" Watch "LOG4J Incompatability" New topic
Author

LOG4J Incompatability

Rennay Dorasamy
Greenhorn

Joined: Jan 08, 2004
Posts: 1
Hi,
We are currently using log4j 1.2.7 for our logging framework. As part of the system architecture, we have to interface with an external vendor. The vendor has provided a java package which uses an older version of log4j that has since been deprecated.
Is it possible to include both versions of log4j in the same application (.ear)? Are there any alternatives? Has anyone experienced a similar problem in the past?
Any comments or feedback would be highly appreciated.
Regards,
Rennay
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Unfortunately, since all the classes in an EAR will be loaded by the same ClassLoader it is not possible to include multiple versions of a product in the same EAR. You have a number of choices:
1) Get the vendor to update their software. (usually this is pretty unlikely)
2) Use the old version of Log4J. Depending on exactly how old the Log4J they are using is this may be very undesirable. I recommend putting a thin wrapper around Log4J if you opt for this so that you can easily update to a newer version in the future if the vendor ever gets their end updated.
3) If possible you could package and deploy the vendor software as a separate EAR (or whatever) and access it that way. This will remove any dependencies on the old version of Log4J from your software.
4) Since Log4J is OSS and under the flexible Apache License... you could always repackage the classes in a different package hierarchy to avoid any name collisions and update your software to access this modified version. This would allow the two Log4J versions to exist simultaneously in a single ClassLoader. Of course, this is less then ideal but given the other options it might be your best choice.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: LOG4J Incompatability