Monday, February 26, 2007

log4j and Websphere Portal

After 3 weeks of my programs not working I was pointed in the right direction by a co-worker. it turns out that for log4j to work properly on my local server, I needed to have the class loader set to PARENT_LAST. I had seen something about this online once, but didn't know what it was talking about.

In my server settings there is a place that adentifies the class loaders for the EAR and WAR files that are in it. These need to be set to PARENT_LAST in order for log4j to work properly.

If using a websphere application (non-portal), this configuration is in the web.xml file. Still everything has to be set to PARENT_LAST in order for it to work.

Apparently having it set to PARENT_FIRST is useful in a live environment because the admin can change the logging setting without redeploying and get additional information from the application, it goes to some general log and not the log that log4j specifies in the properties file, but it's still useful to be able to make that change without redeploying.

Redeploying web apps in order to change a configuration is another annoyance of Java I have learned about. Since an exe is not deployed, but instead a war file (a zip file by another name). I figured we could just modify the contents. But a web server loads the war file into memory one time, and it stays there until the server restarts or that component is shut down or redeployed. In order to make a change the application needs to be redeployed basically. Thus any changes to the WAR file would be useless. I am a bit confused as to the benefit of having so many properties files and xml files on something that cannot be easily changed at runtime however, when the end result is the same as having all of the values hard coded.

1 comment:

DT said...

Can you specify location etc. for this change?
I am trying to implement log4j for websphere portal server.
I added context param in web.xml. Do i need to add anything in portal.xml??