Ivan, thanks for the pointer. I was able to fix the issue by adding the following to the deployment plan:
Note that, even with the class filters, I had to add the <inverse-classloading/> property to prevent commons logging from picking up GeronimoLogFactory from the parent classloader.
Ivan ---08/19/2010 09:36:46 PM---Hi, Refer to this thread, it should be helpful.
08/19/2010 09:36 PM
Re: Issue regarding GeronimoLog
Refer to this thread, it should be helpful.
2010/8/19 Anil Chawla <firstname.lastname@example.org>
We are moving our application to Geronimo and are encountering an issue with GeronimoLog. The core problem is that we are using the Apache Pig library and need to serialize objects created by that library. The Pig classes use the commons logging framework and unfortunately maintain Log references as instance fields rather than static fields -- which means that the Log field is also serialized when the object is serialized. This causes a failure on Geronimo when trying to serialize the Pig objects because the GeronimoLog implementation is not serializable. We are trying to find a solution without modifying all of the Pig classes.
The only solution we have found so far is to dynamically set the "org.apache.commons.logging.LogFactory" system property when our application starts in order to replace the GeronimoLogFactory implementation with our own custom LogFactory implementation. Our custom LogFactory wraps GeronimoLog in order to make it serializable without breaking the normal server logging behavior. The problem with this approach is that it changes the LogFactory implementation for the entire VM and our classes are not available to other applications in the container.
* Is there a way to replace the LogFactory/Log implementation but isolate that change to a specific WAR/EAR within Geronimo?
* Are there any other ideas on how we might work around this issue?
Thanks so much!