log4j commons-logging WAS6.1.0.19 - Websphere

This is a discussion on log4j commons-logging WAS6.1.0.19 - Websphere ; Hello, I user RSA 7.0.0.5 Since i use the fixpack 6.1.0.19 for websphere, no way to use the log4j implementation for commons-logging. I have in /src two files : *commons-logging.properties :* org.apache.commons.logging.Log=org.apache.commons. logging.impl.Log4JLogger *log4j.xml* I use library such as hibernate ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: log4j commons-logging WAS6.1.0.19

  1. log4j commons-logging WAS6.1.0.19

    Hello,

    I user RSA 7.0.0.5

    Since i use the fixpack 6.1.0.19 for websphere, no way to use the log4j implementation for commons-logging.

    I have in /src two files :
    *commons-logging.properties :*
    org.apache.commons.logging.Log=org.apache.commons. logging.impl.Log4JLogger
    *log4j.xml*

    I use library such as hibernate or spring and before the fixpakc 6.1.0.19 all those library (who use commons-logging) log into separate files wich i specified in the log4j.xml. Now, the log goes directly into the console and nothing is logged in files anymore

    I put the log configuration of log4j.xml to debug="true" and i see all the appender and logger are correctly configured.

    I put a breakpoint in one of my class which use commons logging :
    *private Log log = LogFactory.getLog(ProjetBlancPlugin.class);
    log.debug("HELLO");*
    and i can see that the implementation of the Log is : *com.ibm.ws.logging.WsLogger*
    I would like this to be *org.apache.commons.logging.impl.Log4JLogger* (as specified in commons-loggin.properties)

    My web module classloader strategy is PARENT_LAST.

    I repeat this worked before fixpakc 6.1.0.19...

    I anyone knows how to make it work again...
    Thank you. Thieum.

  2. Re: log4j commons-logging WAS6.1.0.19

    *A very strange solution :*
    put in / /profiles//properties/
    the file commons-logging.properties with :
    priority=1
    org.apache.commons.logging.LogFactory=org.apache.c ommons.logging.impl.LogFactoryImpl
    org.apache.commons.logging.Log=org.apache.commons. logging.impl.Log4JLogger

    I don't know which of those lines are really important...

  3. Re: log4j commons-logging WAS6.1.0.19

    The key is appears to be the LogFactory that is being set up. I know the standard JSR47 implementation in WebSphere far better than I know JCL or Log4J ... could you possibly send your sample class so that I can do some remote debugging myself? My suspicion is that both org.apache env vars are needed (first to identify which LogFactory to use in the class and then to identify info to that LogFactory). But if you could send me a sample class, I will see what I can do. Thanks,

  4. Re: log4j commons-logging WAS6.1.0.19

    Hello,
    I am running the WAS 6.1.0.17 within the RAD 7.0.0.6 and have the same Problem.

    I am having the commons-logging.properties with the following settings in the project within the source folders with the following settings.

    org.apache.commons.logging.Log=org.apache.commons. logging.impl.Log4JLogger
    priority=1

    I also tried to put this file to the profile/properties folder.

    Though nothing did work. The Server is instantiating WSLogger instead of Log4JLogger.

    When I am running the same project artifact (ear) on another server, I do get a Log4JLogger :-0 So there must be something within the
    server.

    The EAR's Classloader settings are set to Parent_Last. I checked everything regarding the classloader (I guess) and as I already mentioned these
    settings do word on a second Server. The only difference between those servers that I can see is that the Server where it works is a 6.1.0.7 and the
    one where it does not is 6.1.0.17

    Does anyone have an idea how I can solve this Problem

    Thanks,
    Alex

  5. Re: log4j commons-logging WAS6.1.0.19

    To correct my previous post.
    !! priority=100 !!

  6. Re: log4j commons-logging WAS6.1.0.19

    On Oct 16, 4:14*am, "A.Hachmann" wrote:
    > Hello,
    > I am running the WAS 6.1.0.17 within the RAD 7.0.0.6 and have the same Problem.
    >
    > I am having the commons-logging.properties with the following settings inthe project within the source folders with the following settings.
    >
    > org.apache.commons.logging.Log=org.apache.commons. logging.impl.Log4JLogger
    > priority=1
    >
    > I also tried to put this file to the profile/properties folder.
    >
    > Though nothing did work. The Server is instantiating WSLogger instead of Log4JLogger.
    >
    > When I am running the same project artifact (ear) on another server, I doget a Log4JLogger :-0 So there must be something within the
    > server.
    >
    > The EAR's Classloader settings are set to Parent_Last. I checked everything regarding the classloader (I guess) and as I already mentioned these
    > settings do word on a second Server. The only difference between those servers that I can see is that the Server where it works is a 6.1.0.7 and the
    > one where it does not is 6.1.0.17
    >
    > Does anyone have an idea how I can solve this Problem
    >
    > Thanks,
    > * * * Alex


    Alex,

    Here is how we solved this problem:
    commons-logging.properties is in the root of the WebContent folder in
    RAD 7.0.0.7 (WAS 6.1.0.13)
    log4j.properties is in WebContent/WEB-INF
    In the WEB project's WebContent/META-INF (not WEB-INF) folder we
    created a services folder
    In the services folder we have a file named
    org.apache.commons.logging.LogFactory
    In the org.apache.commons.logging.LogFactory file we have the
    following one line of text:
    "org.apache.commons.logging.impl.Log4jFactory" (without the quotes)
    Both the commons-logging jar and log4j jar are in the in Web Libraries
    for the project which effectively places them in WEB-INF/lib (under
    the covers)
    We have a servlet in our web deployment descriptor that loads on
    startup and uses the Log4j PropertyConfigurator class to initialize
    log4j with the settings in the log4j.properties file mentioned above.

    The rest of our classes can now use the commons logging Log and
    LogFactory classes to log messages via log4j.

    Some J2EE Guy

  7. Re: log4j commons-logging WAS6.1.0.19

    I had a similar problem with my WebApp when upgrading to 6.1.0.19.

    I wasn't using RSA though, and the problem appeared when testing the packaged EAR in WAS. Anyway, here's what I did:

    - Create the following directory-structure in the archive (I did this in my WAR, I haven't tested this in the top-level EAR META-INF):
    {code}/META-INF/services/{code}

    - In /META-INF/services/, create a file named "org.apache.commons.logging.LogFactory"

    - In this file, write down the logging implementation you wish to use, for example:
    {code}org.apache.commons.logging.impl.Log4jFactory {code}

    And that's it.

    I read somewhere that this method isn't supported, but it worked for me.

    It also has the added benefit of not having to fiddle around with the WAS configuration and classloaders.


    Alvin.

  8. Re: log4j commons-logging WAS6.1.0.19

    The solutions suggested seem to relate the the LogFactory discovery process, more information on which is described here for info:

    http://commons.apache.org/logging/co...e-summary.html

    see the section: "Choosing a LogFactory Implementation"

  9. Re: log4j commons-logging WAS6.1.0.19

    The attached doc describes the problem pretty well ... unless you have the Web Services Feature Pack (WSFP) installed. The basic issue is that, when commons-logging.properties was exposed by WebSphere (which was necessary for compatibility with back releases) ... it caused a classLoading order issue. That is, being in the runtime jar, it tended to always be loaded first as long as the default (ParentFirst) classloading policy was in affect. In Jakarta Commons Logging (JCL) 1.1, the priority parm can be used where multiple commons-logging.properties files are in the classpath. Problem is, the JCL API exposed in WebSphere (again in the runtime jar so it gets picked up first under normal classloading policy) is JCL 1.0.3 which did not use priority. The good news is, if you are OK using JCL 1.0.3 ... you can use the services approach already mentioned on this thread. The document tries to go through and explain the options in relatively gory detail including admin console screen shots. If you have WSFP ... best solution appears to be that you put ONLY commons-logging.properties into the sharedLibrary.

  10. Re: log4j commons-logging WAS6.1.0.19

    I would like to make sure this problem is clarified for the audience. I am unwinding a decision at a client that did not look at the root cause of the problem and did not consider the classloader policy when deciding on the solution.

    The overall issue here is the classloader. In WAS we have PARENT_FIRST and PARENT_LAST. Check your setting and what is allowed with your operations team.

    When the classloader policy is set to PARENT_FIRST, please follow the instructions mentioned in the previous post to set the server definitions required to properly operate commons-logging and Log4j.

    When the classloader policy is set to PARENT_LAST, an application may place an upgraded commons-logging JAR ahead of the base classes provided by WAS. For applications that are running with PARENT_LAST, a developer would need to setup the following -

    1. Add the jar to the classpath of the project. For example, commons-logging-1.1.jar.
    2. Add the log4j.properties or log4j.xml to the classpath of the project.
    3. Make sure there is a commons-logging.properties file in the classpath of the project.
    4. Make sure there is the following in the commons-logging.properties

    priority=1
    org.apache.commons.logging.LogFactory=org.apache.c ommons.logging.impl.LogFactoryImpl

    If you are using PARENT_LAST, don't go through all the hassle of server defs when you can solve it locally and not affect other applications on the server.

    Kevin

  11. Re: log4j commons-logging WAS6.1.0.19

    I read somewhere that this method isn't supported, but it worked for me.

    Alvin, it turns out that this approach is supported, and is the preferred method for specifying an alternate LogFactory implementation.

    The WAS InfoCenter suggests this approach as the best practice on this page:
    [http://publib.boulder.ibm.com/infoce...load_jcl.html]

    Thanks for the good advice!

    Andy

  12. Re: log4j commons-logging WAS6.1.0.19

    Hi all,

    I still cannot get this to work. On 6.0.1.13 I had no problem with commons logging. I had a commons-logging.properties file with the following

    priority=1
    org.apache.commons.logging.LogFactory=org.apache.c ommons.logging.impl.LogFactoryImpl

    and no other configuration was needed. I used the default classloader of parent first and everything just worked with commons logging 1.1. Then when I upgraded to 6.1.0.17, logging no longer worked with that configuration.

    So did something change in Websphere between these fix packs?

    I've tried methods suggested above of adding the org.apache.commons.logging.LogFactory file to the META-INF/services directory but it doesn't seem to do the trick.

    Any idea what else I'm missing to get commons logging working on 6.1.0.17? I would prefer not to have to modify the classloader or set up the shared libraries discussed above.

    What is the best approach.

    Thanks

  13. Re: log4j commons-logging WAS6.1.0.19

    michael.a.moynihan@fmr.com wrote:
    > Hi all,
    >
    > I still cannot get this to work. On 6.0.1.13 I had no problem with commons logging. I had a commons-logging.properties file with the following
    >
    > priority=1
    > org.apache.commons.logging.LogFactory=org.apache.c ommons.logging.impl.LogFactoryImpl
    >
    > and no other configuration was needed. I used the default classloader of parent first and everything just worked with commons logging 1.1. Then when I upgraded to 6.1.0.17, logging no longer worked with that configuration.
    >
    > So did something change in Websphere between these fix packs?
    >
    > I've tried methods suggested above of adding the org.apache.commons.logging.LogFactory file to the META-INF/services directory but it doesn't seem to do the trick.
    >
    > Any idea what else I'm missing to get commons logging working on 6.1.0.17? I would prefer not to have to modify the classloader or set up the shared libraries discussed above.
    >
    > What is the best approach.
    >
    > Thanks


    Can you be more specific than 'cannot get this to work' ?

    Ken

  14. Re: log4j commons-logging WAS6.1.0.19

    I had exactly the same problem with 6.1.0.17, and blogged the solution here: http://majikshoe.blogspot.com/2009/0...d-commons.html

    I found that:

    * WAS bundles a "custom" version of Commons Logging that does not include all the classes included in Commons Logging distribution. After running some debugging I found that the distribution WAS bundles appears to be closest to 1.0.3, but WAS does not bundle all the 1.0.3 classes (notably it does not bundle "org.apache.commons.logging.impl.Log4JLogger" which is pretty important for Log4J to work)
    * WAS also bundles a commons-logging.properties file which will be higher in the classloader than yours, so deploying one in your ear will make no difference if you use PARENT FIRST classloading.
    * org.apache.commons.logging.impl.Log4JLogger was deprecated in commons logging 1.0.3 and removed in 1.1, so you _must_ deploy Commons Logging 1.0.x to use that logger.

    Have a look through the blog for how I fixed it in my case.

    I really wish IBM would change the package name for packaged open-source libraries (eg, com.ibm.org.apache.commons.logging). That would prevent these classloading conflicts.

    Hope that helps,
    Jason

  15. Re: log4j commons-logging WAS6.1.0.19

    Hmm the forum software has kindly wrecked the link :-)

    http://majikshoe.blogspot.com/2009/0...d-commons.html

  16. Re: log4j commons-logging WAS6.1.0.19

    If you look back a ways, you will see a Word doc explaining this. Additionally, the February Support Authority column should include it. The basics are as follows:

    If Jakarta Commons Logging (JCL) 1.0.3 is sufficient, then to get to Log4J, you must provide the Log4J jar in your app and then you can set up a file called org.apache.commons.logging.LogFactory in your META-INF/services directory with the content:
    org.apache.commons.logging.impl.Log4JFactory

    If you need a newer version of JCL and can change your application classLoader(s) to ParentLast, then put the Log4J and JCL jars in your app along with the commons-logging.properties in your app.

    If you need a newer version of JCL and cannot use application classLoader(s) set to ParentLast, then move the JCL, Log4J, and commons-logging.properties to a directory. Set up a sharedLib to that directory, and set up a single classLoader to specify that sharedLib as its only class, and have that classLoader specify ParentLast.

    The last option becomes a bit easier in WebSphere 7.0 with the introduction of isolated shared libraries which can be used at the app level instead of the server level. If you search back to the Word Doc or wait for the Support Authority column, you will see better details on this.

  17. Re: log4j commons-logging WAS6.1.0.19

    Hello,

    I found quite a simple solution for this problem, no shared library to add.
    I found it after migrating one of my apps to WSFP (while on WAS 6.1, my JCL 1.1 problem was resolved with classloader on parent last,
    I could not use anymore this solution with WSFP (see MikeC711 documentation [dwWriteUp.doc|http://www.ibm.com/developerworks/fo...dwWriteUp.doc]).

    I have filled a PMR, but no satisfying answer for the moment, hope IBM will publish an official solution for WSFP (you can also check for PMR 72352,122,000 as mentioned in the dwWriteUp.doc).

    Anyway here is the solution (works for WAS 6.1, WSFP. Did not tested on WAS 7 but should work).

    You will need to :
    set application classLoader set to ParentLast.
    download slf4j [http://www.slf4j.org/].
    remove commons-logging.jar from your application.
    add slf4j-api-1.5.8.jar
    add jcl-over-slf4j-1.5.8.jar
    if you want to use log4j, add slf4j-log4j12-1.5.8.jar and of course log4j-.jar.
    if you want to use another logging system just add the appropriate slf4j jar.

    Now you application can continue using JCL APIs while in fact it is using SLF4J implementation which bridges to Log4J or whatever logging system you want.

  18. Re: log4j commons-logging WAS6.1.0.19

    org.apache.commons.logging.impl.Log4jFactory


    I've used it with Spring in my webapp and it works just fine.

    Thanks to IBM support for the good article !

  19. Re: log4j commons-logging WAS6.1.0.19

    Hi ,
    We have same issue on 6.1.0.19 with log4j. Our 6.1.0.19 has both EJB3.0 and WebServices (WSFP) installed , like the caveat in the document. I am just wondering if there has been
    a resolution for this issue on 6.1.0.19 with WSFP ?

    Thanks.

  20. Re: log4j commons-logging WAS6.1.0.19

    We have the same issue (we're using wsfp with no ejb 3).

    Simplest solution I've found is using slf4j (without any code change : just use JCL bridge) and PARENT_LAST. SLF4J setup is explained in this thread.

+ Reply to Thread
Page 1 of 2 1 2 LastLast