log4j in EJB container

All,

Log4j uses static members to access and manage loggers. Given that the EJB specs explicitly tell us not to use non-final static members in the EJB container, is using log4j in EJBs problematic? I'm having a hard time coming up with a real-world exampel of where this would be a problem (although I would expect there would be some situations where class loader issues could cause a loss of state withing the logger manager).

A couple of of questions...

1. Is using log4j in the EJB container something I really need to be concerned about?

2. Other than non-final static data members - which are prohibited - is there a way I can cache and manage 'global' level data or implement a singleton in the EJB container?

3. Is there anything in the new EJB specs that address this whole issue?

[831 byte] By [mlee41a] at [2007-10-2 9:02:30]
# 1

As I've seen in several industrial sized EJB-projects, everybody uses these nonfinal static members to access Logger-objects (which are NOT synchronized). It's a rather pragmatic approach, but I was wondering the same. Even in an EJB book ("EJB Cookbook") they recommended this approach. Couldn't there occurr any racing conditions? Does anyone know this?

For gobal data use a database. It's okay to use nonfinal static variables if they are readonly, but be careful if they are not atomic (eg aggregated objects) anymore.

fkostadinova at 2007-7-16 23:09:27 > top of Java-index,Enterprise & Remote Computing,Enterprise Technologies...