[esb-issues] [JBoss JIRA] Commented: (JBESB-1573) boot.log is truncated upon ESB Server startup

Daniel Bevenius (JIRA) jira-events at lists.jboss.org
Tue Mar 4 02:45:05 EST 2008


    [ 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

       




More information about the esb-issues mailing list