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
