[
http://jira.jboss.com/jira/browse/JBESB-1573?page=comments#action_12401191 ]
Daniel Bevenius commented on JBESB-1573:
----------------------------------------
So this is my take on this....
soapui-client.sar is a scoped service archive. Since log4j.jar is located in its lib
directory, when a call to
Logger.getLogger( name ) is called, the underlying LogManager will be loaded from the
lib/log4.jar. This will
cause the normal Log4j initialization to occur:
• If the log4j.configuration is not defined, then configuration resource log4j.xml is
searched with the following algorithm:
Under JDK 1.2 and later, search for the resource using the thread context class
loader. If
that fails, attempt to locate the resource using the class loader that loaded the
log4j library.
Failing that, one last attempt is made by calling
ClassLoader.getSystemResource(resource) method.
The result of the search, if successful, is always a URL.
• If the resource log4j.xml cannot be located, then search for log4j.properties using
the
above search algorithm.
So, in our case this would mean that the thread context class loader will try to find a
log4j.xml but fail.
Next, it will search for a log4j.properties file using the thread context classloader
which will also fail.
Eventually it will try with the system classloader which looks like this:
java.class.path:
/opt/jboss/as/sjipl/jbossas/bin/run.jar:/opt/java/jdk1.5.0_07/lib/tools.jar
and it will find the log4.propertis in the run.jar archive.
To verify the above, the following code can be placed in code that in located inside the
scoped
application:
Logger rootLogger = Logger.getRootLogger();
log.info( "RootLogger [" + rootLogger.getName() + "]" );
Enumeration allAppenders = rootLogger.getAllAppenders();
while ( allAppenders.hasMoreElements() )
{
Object nextElement = allAppenders.nextElement();
if ( nextElement instanceof FileAppender )
{
FileAppender appender = (FileAppender) nextElement;
log.info( "FileAppender destination : [ " + appender.getFile() +
"]");
}
}
With log4j.jar in the scoped archive this prints:
08:20:26,726 INFO [STDOUT] 08:20:26,725 INFO [SoapUIClientService] RootLogger [root]
08:20:26,726 INFO [STDOUT] 08:20:26,726 INFO [SoapUIClientService] FileAppender
destination : [
/opt/jboss/esb/source/JBESB_4_2_1_GA_CP/product/build/jbossesb-server-4.2.1GA/server/default/log/boot.log]
Without log4j.jar in the scoped archive this prints:
08:23:05,393 INFO [SoapUIClientService] RootLogger [root]
08:23:05,394 INFO [SoapUIClientService] FileAppender destination : [
/opt/jboss/esb/source/JBESB_4_2_1_GA_CP/product/build/jbossesb-server-4.2.1GA/server/default/log/server.log]
So, simply removing log4.jar from the scoped application will we get the behaviour we
expected.
boot.log is truncated upon ESB Server startup
---------------------------------------------
Key: JBESB-1573
URL:
http://jira.jboss.com/jira/browse/JBESB-1573
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Rosetta
Affects Versions: 4.2.1 CP1
Reporter: Daniel Bevenius
Assigned To: Daniel Bevenius
Priority: Critical
boot.log is truncated upon startup of the ESBServer. I've tracked this down to the
soapui-client.sar. By "unscoping" it the boot.log is no longer be truncated. Why
this is happening I'm not sure...I'll continue to investigate but though I create
this Jira in case someone else has any ideas.
This might also be the cause of an issue that we are currently seeing. Our ESB suddenly
starts to log to boot.log at the DEBUG level. This has caused our file system to fill up
and actually stop the servers from handling more requests.
I think I remember something about the soapui-client.sar being scoped because of some
versions conflict, but I can rememeber which it was...jbossws maybe?
I just tested to unscope soapui-client.sar and removed:
jbossesb-rosetta.jar
milyn*,
lib/log4j.jar
lib/commons-logging.jar
I then ran the web service producer quickstart without any trouble. Is this sufficient to
verify that soapui-client.sar can now run unscoped with 4_2_1_GA_CP.
Any thoughs on this would be much appriciated.
Thanks,
Daniel
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira