50-100K eprom with J2ME ram profiles. I'm fine with switching to the xml version of the log4j config.
----- Original Message ----- From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 18, 2002 5:52 PM Subject: Re: [JBoss-dev] log4j.xml > Can I get more details on how JBoss is planned to be used in an embedded > environment? Like this 100-50k memory area will be flash rom? And how ram > are we expecting? I think that it may make sence to provide a special > loader for these cases, where we give it a url and it simply uses the base > URLClassLoaders to pull the very basics. This would allow us to have a very > small boot size but not have to hackup the core network components (or xml > or jmx components) to meet these restrictions. > > I have been thinking about something like this to load the main Server class > from net and I believe that something similar will work for loading the > basic support jars too. > > I assume that embbeded devices will also wanty to use classes with out debug > information, which will buy some more space. > > Short term, what about dropping log4j.properties an use log4j.xml? > > --jason > > > On Mon, 18 Feb 2002, Scott M Stark wrote: > > > .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 > > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
