So, I'm running into some problems where the recommendations for using Log4J clash with the J2EE spec. Before I begin, thanks for the clarification about multiple calls to the PropertyConfigurator.configure method.
Here we go... 1) Defining beans that load at Application Server initialization time. This seems to vendor specific piece of functionality. (Now, the J2EE spec is pretty big, and EJB 1.1 is even bigger. So, I'm open to the possibility that I've missed this in the spec. If someone knows where the spec requires that a server be able to instantiate a bean at startup, please pass this info along. I'm afraid that you'll have to quote from the spec on this one. Just saying it works fine in your server isn't going to cut it.) Even if this supported, the App server (more specifically, the EJB Container) is allowed to distribute instance of beans across multiple JVM's within an Application. So, there is no guarantee that the JVM which instantiated my startup bean (to call PropertyConfigurator.configure) is the same JVM where my other bean will do a Category.getInstance(...). So, I might not be configured in each JVM. 2) Writing to a file specified in the properties file Again the multiple JVM's really wreak havoc. The properties file contains this info at the class level. So, instances of my class in different JVM's (remember they are all part of the same J2EE application and will see the same properties file) will be attempting to write to the same place (unsynchronized between the JVMs). Not to mention that beans "must not use the java.io package to attempt to access files and directories in the file system". (EJB Specification, v1.1, Sun Microsystems, Pg273) [Does this mean that the only way to reliably log in a J2EE environment is to send log info down a socket to some listener who is assembling all the info for the application?] 3) Using the Runtime.addShutdownHook method to cleanup/close Appenders Wouldn't this violate the EJB1.1 edict against trying to manage threads? 4) properties file Wouldn't reading from the properties file also violate the java.io restriction? Maybe this all points to only being able to use Log4J in a very specific way inside J2EE (or maybe it just means I missed something terribly important at a very basic level). In any event, I think some clarification will be useful to all. Dave -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 02.October 2001 02:50 To: LOG4J Users Mailing List Subject: Re: PropertyConfigurator.configure method in J2EE At 16:08 01.10.2001 -0400, David Schultz wrote: >If I understand the documentation and discussion threads properly, the >configure method of the PropertyConfigurator class should only be called >once be JVM. (Multiple calls result in multiple occurences of output data >in the logs.) That is not entirely correct. If a configuration file is reloaded, then any category mentioned in the config file will have its appenders closed and removed. The duplication will not occur. >So, when using a J2EE server, where is the appropriate place for putting the >configure call? Can't you define beans that are loaded at Aplicication Server initialization time? >(From the documentation, it is clear how to setup the Tomcat servlet engine >to only configure once. A program with a main() is obvious. However, about >the only thing I have seen for J2EE is to have a stateless session bean for >performing the configure. I guess this would be something done by an >administrator once the server was brought up. However, it seems like there >should be a cleaner way.) > >On a related note, I don't see people talking about the shutdown method of >the Category class. Are people just assuming that is okay to let an >application terminate without closing any open output streams? Again, with >a main() this is obvious. Although this doesn't seem to be discussed for >Tomcat or J2EE servers. You can use JDK 1.3 shutdown hooks. See Runtime.addShutdownHook(Thread) for more details. -- Ceki Gülcü - http://qos.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
