.5Mb is huge for an embedded device. We are going to get rid of the xml parsers from the bootpath and as much else as we can with a goal of being well under 100k, preferably under 50k as the minimum boot size. Figure out how to make log4j work from a net download.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 6:47 PM Subject: Re: [JBoss-dev] log4j.xml > 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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
