I\'m build a Portlet application deployed to a WebSphere Portal Server running on Linux. Every Portlet WAR uses Log4j for logging with a configuration like this, having ever
I'm not sure why log4j is stopping in your application. But you could (should) upgrade to log4j 2.0. Switching shouldn't be much effort. You will need to rewrite your log4j.properties file to an XML file because the new version doesn't support properties file any longer.
In the Java Magazin an article stated that log4j 2.0 is behaving more robust in multithreaded environments, so there is a chance it will fix your issue. If it doesn't you still have the benefit of the new version.
It brings some nice features and enhancements (copied from the log4j site):
API Separation
The API for Log4j is separate from the implementation making it clear for application developers which classes and methods they can use while ensuring forward compatibility. This allows the Log4j team to improve the implementation safely and in a compatible manner.
Improved Performance
Log4j 2 performs faster than Log4j 1.x in critical areas and similarly to Logback under most circumstances. See Performance for more information. Support for multiple APIs While the Log4j 2 API will provide the best performance, Log4j 2 provides support for the SLF4J and Commons Logging APIs.
Automatic Reloading of Configurations
Like Logback, Log4j 2 can automatically reload its configuration upon modification. Unlike Logback, it will do so without losing log events while reconfiguration is taking place.
Advanced Filtering
Like Logback, Log4j 2 supports filtering based on context data, markers, regular expressions, and other components in the Log event. Filtering can be specified to apply to all events before being passed to Loggers or as they pass through Appenders. In addition, filters can also be associated with Loggers. Unlike Logback, you can use a common Filter class in any of these circumstances.
Plugin Architecture
Log4j uses the plugin pattern to configure components. As such, you do not need to write code to create and configure an Appender, Layout, Pattern Converter, and so on. Log4j automatically recognizes plugins and uses them when a configuration references them.
Property Support
You can reference properties in a configuration, Log4j will directly replace them, or Log4j will pass them to an underlying component that will dynamically resolve them. Properties come from values defined in the configuration file, system properties, environment variables, the ThreadContext Map, and data present in the event. Users can further customize the property providers by adding their own Lookup Plugin.