The problem isn't the URLCL vs UCL loader issue at this point. The problem is that there is nothing in the UCL repository as you say. Therefore it makes no sense to intialize the Log4jService as this point. Just moving the Log4jService setup to the core conf/jboss-service.xml descriptor and out of ServerImpl solves the problem. The only issue I see is that the initial startup info including the loading of the lib jars is not showing up in the server.log.
There is also this message on the console at the end of shutdown: [INFO,Log4jService] Stopping log4j:ERROR No appenders could be found for category (org.jboss.logging.Log4jService). log4j:ERROR Please initialize the log4j system properly. because ServiceMBeanSupport is logging after the Log4jService shtudown Category. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Scott M Stark" <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 10:59 AM Subject: Re: [JBoss-dev] Going to log4j 1.2.2 for 3.x Ok, I understand more now... though you know that log4j.properties is going to be used even before ServerImpl gets created right... It looks like the UCL bits should be operable at the time when Log4jService is created... the TCL is set right before it is started. But I would guess (since I am not a CL expert) that since we have not processed the classpath element from jboss-service.xml, we have not populated the UCL repo with anything useful, short of the conf directory (as set by ServerImpl.initBootLibraries()). If there were UCL's for each registered boot library, would the UCL be used, or would the URLCL be used? If the UCL will be used, then what problems would arise if we either installed a UCL for each URLCL, or rather than using a URLCL, use a boot strap UCL, which will only load the required boot classes from the URLCL, then once the repo is active will force all classes to go through it. This will mean that classes loaded on the URLCL will be serialized right... but we don't really care too much about that. If the above makes sence, then I think it would be worth the effort to implement that rather than add to the logging configuration complexity... but I am not sure if the above will work. --jason _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
