当类加载器设置为父级时，log4j日志在Websphere中不起作用

Question

I am having two problems. In my application we are using custom email functionality with javax.mail api. Mails are going fine with out any error when the class loader setting is kept as Parent First but custom logs are not getting generated with that class loader setting.

When I update the class loader to Parent Last then logs are getting generated but the custom email functionality is not working, its getting freezed at message.saveChanges(); line and server is throwing time out error.

I have mail.jar & log4j.jar included in the WEB-INF/lib of the application and the log4j.properties file is present in the classes folder

Could any one please let me know what is causing this issue and Is there a way to make both logging and email functionality work with a single class loader setting.

Thanks.

Answer 1

This most likely is caused because Log4J doesn't load the configuration file ( log4j.xml or log4j.properties ) that you think it does.

Add the log4j.debug=true system property, restart the server and watch the logs. The logs (in SystemOut.log or SystemErr.log ) will tell you exactly which configuration file was loaded.

Answer 2

Your version of JavaMail must be fairly old since you are using the 'mail.jar'.

Upgrade the JavaMail included with websphere to 1.5.3 which contains the fix for Bug 6668 -skip unusable Store and Transport classes . From the bug report:

In complex class loading situations, it can be possible for there to be multiple copies of the JavaMail classes. A Store or Transport defined by one copy may be loaded by another copy, but it won't be usable because they're in different ClassLoaders. In this case, JavaMail should skip over the unusable class and try to load the class from another ClassLoader.

This can happen, for example, in GlassFish if the application includes the JavaMail classes, the application class loader is configured to prefer application classes over system classes, and the app server itself tries to use JavaMail when running in the context of the application.

You need to then remove that old version of JavaMail from your WEB-INF/lib and if need be, place JavaMail 1.5.3 in WEB-INF/lib too. I've tested this fix for GlassFish so I'm assuming lots of other appservers suffer this same issue.

You can download the latest snapshot and official releases from the JavaMail reference implementation home page.