After looking into this further it looks like when Category loads it will attempt to load log4j.properties and process it. We can turn that off by default by setting -Dlog4j.defaultInitOverride=true, but I am not sure that is a good idea.
I think that this all stemmed from configuration being read from system resources. This isn't really the case anymore. In fact this might be the only service left which does that... well at least most other services do not. So, I am thinking that it would be a good idea to update this to use the ServerConfig.getConfigURL() as the base for looking for configuration files. But, then to make this work and not just move the problem, we would have to remove that URL from the classpath... which I am not so sure of either. I also found a small window where log events maybe lost... which is between the time that ServiceLibraies is fully loaded and able to pull the log4j.jar and load it and before Log4jService has been started. Note, that because of the current bahavior, when Category loads it will configure using log4j.properties so some odd results may occur if you are expecting log4j.xml to be used. To debug this problem I played with using BoostrapLogger in Log4jService, which I expected would have just logged to System.out, but I found that it did not log until the Category.getRoot() method had been called in Log4jService. I then played around a little more, adding a flag in BootstrapLogger which would be set by Log4jService when it was actually initialized and ready, which finally did the trick to show the messages. Of course I had to disable the default configuration behavior of Category too, or delete log4j.properties * * * So this all seems a little wacked out to me. Essentially Log4jService only duplicates the functionality of what Log4j does already. Once we removed jboss.conf, and were forced to add a system property to change the config file we just added to the duplication. I think this should be changed... but I can't really see how. First, I think that we should put a stripped down version of log4j.jar into jboss/lib and drop the usage of BootstrapLogger. I understand that we want to pull as much from the network as possible, but I suggest that this one should be left local for the following reasons: o JBoss can not exist with out this. Since we do abstract its usage into our own Logger it is conceivable that we could remove it but I think that doing so would be highly unlikely.o Not really a strong point, but a point none-the-less. o It is not possible to provide rich debugging of the core service library classes because the log4j classes have to be loaded through them. o BootstrapLogger introduces a window which makes it possible to loose events. As the loading system changes over time this may cause some confusion over where logging events are going. o BootstrapLogger complicates it does not simplify. So, if we put log4j-core.jar into jboss/lib, and make Logger (and priotity friends) part of the jboss-boot.jar, we can use the exact same Logger objects through the entire system. We can use the default behavior of Log4j to try and configure from a log4j.properties file. This mechanism can be used to enable debugging of the boot process, until Log4jService can be loaded. I still think this is nessicary because we will want to use the logging config for the net config the user is running under. This means that we will either have to stop putting configURL into the classpath, or that we should provide a log4j.properties in jboss-boot.jar (or run.jar) which provides the initial configuration, and not interfere with the configuration setup by Log4jService. It seems like the advantages of doing this will allow us to see more debug on core components, removes any windows or jboss specific log4j problems caused by the BL, exposed more control over the exact handling of log messages during boot which can be configured in standard log4j ways. The only disadvantage that I can see is another file on the local classpath. With log4j-core.jar added to lib/ the size of the directory is 584k, still incredibly tiny. It will still fit on a floppy with lots of room to spare. This file is only 76k itself. This feels like the right thing todo. What do you think? --jason On Sun, 2002-02-17 at 16:32, Jason Dillon wrote: > I don't understand why yet, but even when using the config property to > override the file file, if a .properties exists it will be used. > > Any idea why this is the case? > > --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
