Topic
  • 30 replies
  • Latest Post - ‏2012-06-19T06:16:47Z by porschemad911
SystemAdmin
SystemAdmin
37422 Posts

Pinned topic log4j commons-logging WAS6.1.0.19

‏2008-09-25T08:49:38Z |
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.
Updated on 2012-06-19T06:16:47Z at 2012-06-19T06:16:47Z by porschemad911
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-09-25T09:25:58Z  
    A very strange solution :
    put in /<was_home>/profiles/<profile_name>/properties/
    the file commons-logging.properties with :
    priority=1
    org.apache.commons.logging.LogFactory=org.apache.commons.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...
  • MikeC711
    MikeC711
    4 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-10-14T13:26:16Z  
    A very strange solution :
    put in /<was_home>/profiles/<profile_name>/properties/
    the file commons-logging.properties with :
    priority=1
    org.apache.commons.logging.LogFactory=org.apache.commons.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...
    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,
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-10-16T08:14:16Z  
    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
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-10-16T08:20:59Z  
    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
    To correct my previous post.
    !! priority=100 !!
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-10-18T14:16:55Z  
    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):
    /META-INF/services/ 
    


    • 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:
    org.apache.commons.logging.impl.Log4jFactory
    


    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.
    Updated on 2014-03-26T01:08:30Z at 2014-03-26T01:08:30Z by iron-man
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-12-17T10:48:24Z  
    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):
    <pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">/META-INF/services/ </pre>

    • 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:
    <pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">org.apache.commons.logging.impl.Log4jFactory </pre>

    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.
    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/commons-logging-1.0.4/docs/apidocs/org/apache/commons/logging/package-summary.html

    see the section: "Choosing a LogFactory Implementation"
  • MikeC711
    MikeC711
    4 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-12-17T12:46:19Z  
    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/commons-logging-1.0.4/docs/apidocs/org/apache/commons/logging/package-summary.html

    see the section: "Choosing a LogFactory Implementation"
    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.

    Attachments

  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-12-19T19:38:01Z  
    • MikeC711
    • ‏2008-12-17T12:46:19Z
    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.
    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.commons.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
  • andymc_
    andymc_
    78 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2008-12-19T19:55:12Z  
    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):
    <pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">/META-INF/services/ </pre>

    • 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:
    <pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">org.apache.commons.logging.impl.Log4jFactory </pre>

    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.
    > alvin.p wrote:
    > 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/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/ttrb_classload_jcl.html

    Thanks for the good advice!

    Andy
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-01-16T22:11:09Z  
    • andymc_
    • ‏2008-12-19T19:55:12Z
    > alvin.p wrote:
    > 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/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/ttrb_classload_jcl.html

    Thanks for the good advice!

    Andy
    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.commons.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
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-01-18T23:39:11Z  
    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.commons.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
    I had exactly the same problem with 6.1.0.17, and blogged the solution here: http://majikshoe.blogspot.com/2009/01/joys-of-websphere-61-and-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
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-01-18T23:41:10Z  
    I had exactly the same problem with 6.1.0.17, and blogged the solution here: http://majikshoe.blogspot.com/2009/01/joys-of-websphere-61-and-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
    Hmm the forum software has kindly wrecked the link :-)

    http://majikshoe.blogspot.com/2009/01/joys-of-websphere-61-and-commons.html
  • MikeC711
    MikeC711
    4 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-01-19T02:23:26Z  
    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.commons.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
    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.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-06-18T21:15:51Z  
    • MikeC711
    • ‏2009-01-19T02:23:26Z
    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.
    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).

    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.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-06-23T18:41:54Z  
    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).

    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.
    One last solution using WSFP is using JCL 1.0.3 (and not 1.1.1).

    Just follow instructions in http://www.ibm.com/developerworks/websphere/techjournal/0901_supauth/0901_supauth.html :

    >If you prefer to use Log4J to handle the logging done with JCL 1.0.3, then some simple configuration is necessary:
    >
    > 1. Include the Log4J JAR and JCL 1.0.3 JAR in your application’s WEB-INF/lib directory.
    > 2. Create a file called org.apache.commons.logging.LogFactory in your application’s META-INF/services directory. This file contains just one >line of text:
    >
    > 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 !
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-09T20:24:42Z  
    • MikeC711
    • ‏2008-12-17T12:46:19Z
    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.
    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.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-11T13:06:58Z  
    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.
    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.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-14T17:31:21Z  
    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.
    Hi,
    I tried changing the class loader to Parent last , using slf4j like you described , however the application gives a different error now saying that it cant find helper classes for the webservices beans , as soon as a webservice call is received. Before (with parent first) , it at least would go past that and fail on log4j. I can see the classes in the web-inf/classes inside installed applications folder.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-14T18:01:07Z  
    Hi,
    I tried changing the class loader to Parent last , using slf4j like you described , however the application gives a different error now saying that it cant find helper classes for the webservices beans , as soon as a webservice call is received. Before (with parent first) , it at least would go past that and fail on log4j. I can see the classes in the web-inf/classes inside installed applications folder.
    Is there any other way to get this log4j class loading issue resolved on 6.1.0.19(with WSFP) without changing class loader policy to parent last (which is creating some other problems of its own). Thanks.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-15T07:37:55Z  
    Is there any other way to get this log4j class loading issue resolved on 6.1.0.19(with WSFP) without changing class loader policy to parent last (which is creating some other problems of its own). Thanks.
    Perhaps using JCL 1.0.3 (and not 1.1.x) as explained in http://www.ibm.com/developerworks/websphere/techjournal/0901_supauth/0901_supauth.html ?

    I don't remember if I had to use PARENT_LAST though

    Extract from the article :
    JCL V1.0.3
    . JCL routing through Log4J
    If you prefer to use Log4J to handle the logging done with JCL 1.0.3, then some simple configuration is necessary:
    1. Include the Log4J JAR and JCL 1.0.3 JAR in your application’s WEB-INF/lib directory.
    2. Create a file called org.apache.commons.logging.LogFactory in your application’s META-INF/services directory.
    This file contains just one line of text: org.apache.commons.logging.impl.Log4jFactory

    Otherwise if you have pb with PARENT_LAST, just post your stacktrace, perhaps someone will know your pb and you'll be able to work with PARENT_LAST ?
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-15T17:45:56Z  
    Perhaps using JCL 1.0.3 (and not 1.1.x) as explained in http://www.ibm.com/developerworks/websphere/techjournal/0901_supauth/0901_supauth.html ?

    I don't remember if I had to use PARENT_LAST though

    Extract from the article :
    JCL V1.0.3
    . JCL routing through Log4J
    If you prefer to use Log4J to handle the logging done with JCL 1.0.3, then some simple configuration is necessary:
    1. Include the Log4J JAR and JCL 1.0.3 JAR in your application’s WEB-INF/lib directory.
    2. Create a file called org.apache.commons.logging.LogFactory in your application’s META-INF/services directory.
    This file contains just one line of text: org.apache.commons.logging.impl.Log4jFactory

    Otherwise if you have pb with PARENT_LAST, just post your stacktrace, perhaps someone will know your pb and you'll be able to work with PARENT_LAST ?
    Hi,
    This is the stack trace with Parent Last Class loading ( I apologize for having to mask the package name due to some obscure company policy) , this error happens only on Parent Last.:
    The first line abt having to implement xml.rpc.handler.Handler is also not correct. My handler does extend GenericHandler which implements that.
    7/15/09 13:32:04:090 EDT 00000037 WSDDJAXRPCHan E com.ibm.ws.webservices.engine.deployment.wsdd.WSDDJAXRPCHandlerInfo getJavaClass WSWS3123E: Error: Javaclass com.*****.******.******.services.handlers.ProviderPaymentHandler specified for handler null must implement javax.xml.rpc.handler.Handler OR com.ibm.wsspi.webservices.rpc.handler.HandlerClassFactory. The handler will be skipped.
    7/15/09 13:32:07:590 EDT 00000037 PivotHandlerW E com.ibm.ws.webservices.engine.PivotHandlerWrapper bindExceptionToResponse WSWS3400I: Info: unexpected exception.
    java.lang.NoClassDefFoundError: com.*****.******.******.services.beans.ProviderPaymentRequest_Helper (initialization failure)
    at java.lang.J9VMInternals.initialize(J9VMInternals.java:132)
    at java.lang.Class.forNameImpl(Native Method)
    at java.lang.Class.forName(Class.java:163)
    at com.ibm.ws.webservices.engine.utils.ClassUtils$2.run(ClassUtils.java:234)
    at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
    at com.ibm.ws.webservices.engine.utils.ClassUtils.loadClass(ClassUtils.java:210)
    at com.ibm.ws.webservices.engine.utils.ClassUtils.forName(ClassUtils.java:181)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory$getDeserializerMethodPRIV.run(BaseDeserializerFactory.java:359)
    at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory.getDeserializerMethod(BaseDeserializerFactory.java:253)
    at com.ibm.ws.webservices.engine.encoding.ser.BeanDeserializerFactory.getDeserializerMethod(BeanDeserializerFactory.java:216)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory.lazyInitialization(BaseDeserializerFactory.java:154)
    at com.ibm.ws.webservices.engine.encoding.ser.BeanDeserializerFactory.lazyInitialization(BeanDeserializerFactory.java:132)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory.getDeserializerAs(BaseDeserializerFactory.java:168)
    at com.ibm.ws.webservices.engine.encoding.DeserializationContextImpl.getDeserializer(DeserializationContextImpl.java:438)
    at com.ibm.ws.webservices.engine.xmlsoap.builders.RequestResponseProcessor.onStartChild(RequestResponseProcessor.java:356)
    at com.ibm.ws.webservices.engine.events.P2DConverter.startElement(P2DConverter.java:403)
    at com.ibm.ws.webservices.engine.events.P2DConverter.startElement(P2DConverter.java:344)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.startElementAction(SAX2ParserBase.java:234)
    at com.ibm.xml.xlxp.api.was.WSXMLReader.startElementAction(WSXMLReader.java:122)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.startElementEvent(SAX2ParserBase.java:220)
    at com.ibm.xml.xlxp.api.was.WSXMLReader$WSScannerHelper.produceStartElementEvent(WSXMLReader.java:351)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.finishStartElement(SimpleScannerHelper.java:539)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.scanStartElementUnbuffered(DocumentEntityScanner.java:3527)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.scanStartElementUnbuffered(SimpleScannerHelper.java:767)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.stateUnbufferedStartElement(DocumentEntityScanner.java:503)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.scanContentUnbuffered(DocumentEntityScanner.java:2762)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.scanContentUnbuffered(SimpleScannerHelper.java:1072)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.stateUnbufferedContent(DocumentEntityScanner.java:547)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.produceEvent(DocumentEntityScanner.java:640)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.produceEvents(DocumentEntityScanner.java:665)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.parseDocumentEntity(DocumentEntityScanner.java:429)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.parseDocumentEntity(SimpleScannerHelper.java:183)
    at com.ibm.xml.xlxp.api.was.WSXMLReader.parseEvents(WSXMLReader.java:115)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.parseEntity(SAX2ParserBase.java:1337)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.parse(SAX2ParserBase.java:1376)
    at javax.xml.parsers.SAXParser.parse(Unknown Source)
    at com.ibm.ws.webservices.engine.utils.WebServicesParser.parse(WebServicesParser.java:342)
    at com.ibm.ws.webservices.engine.encoding.DeserializationContextImpl.parse(DeserializationContextImpl.java:295)
    at com.ibm.ws.webservices.engine.SOAPPart._getSOAPEnvelope(SOAPPart.java:1064)
    at com.ibm.ws.webservices.engine.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:628)
    at com.ibm.ws.webservices.engine.SOAPPart.getEnvelope(SOAPPart.java:656)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandlerChain.handleRequest(JAXRPCHandlerChain.java:301)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler.invokeServerRequestHandler(JAXRPCHandler.java:506)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler$1.invoke(JAXRPCHandler.java:380)
    at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:208)
    at com.ibm.ws.webservices.engine.WebServicesEngine.invoke(WebServicesEngine.java:336)
    at com.ibm.ws.webservices.engine.transport.http.WebServicesServlet.doPost(WebServicesServlet.java:831)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
    at com.ibm.ws.webservices.engine.transport.http.WebServicesServletBase.service(WebServicesServletBase.java:341)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1103)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:570)
    at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:486)
    at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3440)
    at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267)
    at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:815)
    at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1461)
    at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:118)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
    at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
    at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
    at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
    at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
    at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
    at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
    at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)
    Caused by: java.lang.VerifyError: com/ibm/ws/webservices/engine/utils/QNameTable.createQName(Ljava/lang/String;Ljava/lang/String;)Ljavax/xml/namespace/QName;
    at com.*****.******.******.services.beans.ProviderPaymentRequest_Helper.<clinit>(ProviderPaymentRequest_Helper.java:20)
    at java.lang.J9VMInternals.initializeImpl(Native Method)
    at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)
    at java.lang.Class.forNameImpl(Native Method)
    at java.lang.Class.forName(Class.java:163)
    at com.ibm.ws.webservices.engine.utils.ClassUtils$1.run(ClassUtils.java:164)
    at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
    at com.ibm.ws.webservices.engine.utils.ClassUtils.forName(ClassUtils.java:157)
    ... 65 more
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-15T17:51:01Z  
    Hi,
    This is the stack trace with Parent Last Class loading ( I apologize for having to mask the package name due to some obscure company policy) , this error happens only on Parent Last.:
    The first line abt having to implement xml.rpc.handler.Handler is also not correct. My handler does extend GenericHandler which implements that.
    7/15/09 13:32:04:090 EDT 00000037 WSDDJAXRPCHan E com.ibm.ws.webservices.engine.deployment.wsdd.WSDDJAXRPCHandlerInfo getJavaClass WSWS3123E: Error: Javaclass com.*****.******.******.services.handlers.ProviderPaymentHandler specified for handler null must implement javax.xml.rpc.handler.Handler OR com.ibm.wsspi.webservices.rpc.handler.HandlerClassFactory. The handler will be skipped.
    7/15/09 13:32:07:590 EDT 00000037 PivotHandlerW E com.ibm.ws.webservices.engine.PivotHandlerWrapper bindExceptionToResponse WSWS3400I: Info: unexpected exception.
    java.lang.NoClassDefFoundError: com.*****.******.******.services.beans.ProviderPaymentRequest_Helper (initialization failure)
    at java.lang.J9VMInternals.initialize(J9VMInternals.java:132)
    at java.lang.Class.forNameImpl(Native Method)
    at java.lang.Class.forName(Class.java:163)
    at com.ibm.ws.webservices.engine.utils.ClassUtils$2.run(ClassUtils.java:234)
    at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
    at com.ibm.ws.webservices.engine.utils.ClassUtils.loadClass(ClassUtils.java:210)
    at com.ibm.ws.webservices.engine.utils.ClassUtils.forName(ClassUtils.java:181)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory$getDeserializerMethodPRIV.run(BaseDeserializerFactory.java:359)
    at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory.getDeserializerMethod(BaseDeserializerFactory.java:253)
    at com.ibm.ws.webservices.engine.encoding.ser.BeanDeserializerFactory.getDeserializerMethod(BeanDeserializerFactory.java:216)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory.lazyInitialization(BaseDeserializerFactory.java:154)
    at com.ibm.ws.webservices.engine.encoding.ser.BeanDeserializerFactory.lazyInitialization(BeanDeserializerFactory.java:132)
    at com.ibm.ws.webservices.engine.encoding.ser.BaseDeserializerFactory.getDeserializerAs(BaseDeserializerFactory.java:168)
    at com.ibm.ws.webservices.engine.encoding.DeserializationContextImpl.getDeserializer(DeserializationContextImpl.java:438)
    at com.ibm.ws.webservices.engine.xmlsoap.builders.RequestResponseProcessor.onStartChild(RequestResponseProcessor.java:356)
    at com.ibm.ws.webservices.engine.events.P2DConverter.startElement(P2DConverter.java:403)
    at com.ibm.ws.webservices.engine.events.P2DConverter.startElement(P2DConverter.java:344)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.startElementAction(SAX2ParserBase.java:234)
    at com.ibm.xml.xlxp.api.was.WSXMLReader.startElementAction(WSXMLReader.java:122)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.startElementEvent(SAX2ParserBase.java:220)
    at com.ibm.xml.xlxp.api.was.WSXMLReader$WSScannerHelper.produceStartElementEvent(WSXMLReader.java:351)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.finishStartElement(SimpleScannerHelper.java:539)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.scanStartElementUnbuffered(DocumentEntityScanner.java:3527)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.scanStartElementUnbuffered(SimpleScannerHelper.java:767)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.stateUnbufferedStartElement(DocumentEntityScanner.java:503)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.scanContentUnbuffered(DocumentEntityScanner.java:2762)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.scanContentUnbuffered(SimpleScannerHelper.java:1072)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.stateUnbufferedContent(DocumentEntityScanner.java:547)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.produceEvent(DocumentEntityScanner.java:640)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.produceEvents(DocumentEntityScanner.java:665)
    at com.ibm.xml.xlxp.scan.DocumentEntityScanner.parseDocumentEntity(DocumentEntityScanner.java:429)
    at com.ibm.xml.xlxp.api.util.SimpleScannerHelper.parseDocumentEntity(SimpleScannerHelper.java:183)
    at com.ibm.xml.xlxp.api.was.WSXMLReader.parseEvents(WSXMLReader.java:115)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.parseEntity(SAX2ParserBase.java:1337)
    at com.ibm.xml.xlxp.api.sax.impl.SAX2ParserBase.parse(SAX2ParserBase.java:1376)
    at javax.xml.parsers.SAXParser.parse(Unknown Source)
    at com.ibm.ws.webservices.engine.utils.WebServicesParser.parse(WebServicesParser.java:342)
    at com.ibm.ws.webservices.engine.encoding.DeserializationContextImpl.parse(DeserializationContextImpl.java:295)
    at com.ibm.ws.webservices.engine.SOAPPart._getSOAPEnvelope(SOAPPart.java:1064)
    at com.ibm.ws.webservices.engine.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:628)
    at com.ibm.ws.webservices.engine.SOAPPart.getEnvelope(SOAPPart.java:656)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandlerChain.handleRequest(JAXRPCHandlerChain.java:301)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler.invokeServerRequestHandler(JAXRPCHandler.java:506)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler$1.invoke(JAXRPCHandler.java:380)
    at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:208)
    at com.ibm.ws.webservices.engine.WebServicesEngine.invoke(WebServicesEngine.java:336)
    at com.ibm.ws.webservices.engine.transport.http.WebServicesServlet.doPost(WebServicesServlet.java:831)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
    at com.ibm.ws.webservices.engine.transport.http.WebServicesServletBase.service(WebServicesServletBase.java:341)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1103)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:570)
    at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:486)
    at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3440)
    at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267)
    at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:815)
    at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1461)
    at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:118)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
    at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
    at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
    at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
    at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
    at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
    at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
    at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)
    Caused by: java.lang.VerifyError: com/ibm/ws/webservices/engine/utils/QNameTable.createQName(Ljava/lang/String;Ljava/lang/String;)Ljavax/xml/namespace/QName;
    at com.*****.******.******.services.beans.ProviderPaymentRequest_Helper.<clinit>(ProviderPaymentRequest_Helper.java:20)
    at java.lang.J9VMInternals.initializeImpl(Native Method)
    at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)
    at java.lang.Class.forNameImpl(Native Method)
    at java.lang.Class.forName(Class.java:163)
    at com.ibm.ws.webservices.engine.utils.ClassUtils$1.run(ClassUtils.java:164)
    at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
    at com.ibm.ws.webservices.engine.utils.ClassUtils.forName(ClassUtils.java:157)
    ... 65 more
    Perhaps you have QName class in multiple jars (you should only use the class loaded by websphere).
    If you're using eclipse, just CTRL+SHIFT+T and search for QName, it will give you all jars containing this class.

    If you have it in your ear or web-inf/lib, that's it.

    But be cautious, perhaps you need the version you have in you app (WSFP QName class is for JAX-WS 2.0, while some ws engine use JAX-WS2.1 which use another version of QName class).
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-15T20:36:40Z  
    Perhaps you have QName class in multiple jars (you should only use the class loaded by websphere).
    If you're using eclipse, just CTRL+SHIFT+T and search for QName, it will give you all jars containing this class.

    If you have it in your ear or web-inf/lib, that's it.

    But be cautious, perhaps you need the version you have in you app (WSFP QName class is for JAX-WS 2.0, while some ws engine use JAX-WS2.1 which use another version of QName class).
    Hi,

    I have jax-rpc.jar in my web-inf/lib which has QName class , but that is needed by some classes in the application. Basically , this is what my app does:
    It hosts some WS-I Compliant webservices , but also consumes third party webservices which are not ws-i compliant and hence the axis and jax-rpc jars in web-inf/lib. Also the application is using openJPA. Everyhting is working on 6.1.0.17 , no issues. On 6.1.0.19 , with default class loading(parent first) my application seems to find log4j without any issues , but when the OpenJPA tries to initialize persistence env. it complains that log4j.priority class is not found and fails to initialize . If i change the class loading policy to parent last ,i get the NoClass def on handler class.
    Thanks for all your time.
  • SystemAdmin
    SystemAdmin
    37422 Posts

    Re: log4j commons-logging WAS6.1.0.19

    ‏2009-07-15T22:16:59Z  
    Perhaps you have QName class in multiple jars (you should only use the class loaded by websphere).
    If you're using eclipse, just CTRL+SHIFT+T and search for QName, it will give you all jars containing this class.

    If you have it in your ear or web-inf/lib, that's it.

    But be cautious, perhaps you need the version you have in you app (WSFP QName class is for JAX-WS 2.0, while some ws engine use JAX-WS2.1 which use another version of QName class).
    This is the stack trace with default class loading (parent first) on 6.1.0.19 :

    7/15/09 15:48:07:014 EDT 0000002a PivotHandlerW E com.ibm.ws.webservices.engine.PivotHandlerWrapper bindExceptionToResponse WSWS3400I: Info: unexpected exception.
    java.lang.NoClassDefFoundError: org.apache.log4j.Priority
    at java.lang.J9VMInternals.verifyImpl(Native Method)
    at java.lang.J9VMInternals.verify(J9VMInternals.java:68)
    at java.lang.J9VMInternals.initialize(J9VMInternals.java:129)
    at org.apache.openjpa.lib.log.Log4JLogFactory.newLogAdapter(Log4JLogFactory.java:33)
    at org.apache.openjpa.lib.log.LogFactoryAdapter.getLog(LogFactoryAdapter.java:40)
    at org.apache.openjpa.lib.conf.ConfigurationImpl.getLog(ConfigurationImpl.java:225)
    at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getConfigurationLog(OpenJPAConfigurationImpl.java:1475)
    at org.apache.openjpa.persistence.PersistenceProductDerivation$ConfigurationProviderImpl.setInto(PersistenceProductDerivation.java:426)
    at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFactory.java:59)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:618)
    at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:124)
    at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:62)
    at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:78)
    at com.ibm.websphere.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:64)
    at com.ibm.websphere.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:34)
    at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:87)
    at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:52)
    at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
    at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
    at com.bcbssc.fastar.api.common.util.PersistenceUtil.getEntityManagerFactory(PersistenceUtil.java:46)
    at com.bcbssc.fastar.api.common.util.TransactionUtil.<init>(TransactionUtil.java:34)
    at com.bcbssc.fastar.api.services.handlers.ProviderPaymentHandler.handleRequest(ProviderPaymentHandler.java:45)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.HandlerProxy.handleRequest(HandlerProxy.java:145)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandlerChain.handleRequest(JAXRPCHandlerChain.java:334)
    at com.ibm.ws.webservices.engine.handlers.soap.SOAPHandlerChain.handleRequest(SOAPHandlerChain.java:176)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler.invokeServerRequestHandler(JAXRPCHandler.java:506)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCSOAPHandler.invokeServerRequestHandler(JAXRPCSOAPHandler.java:184)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler$1.invoke(JAXRPCHandler.java:380)
    at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:208)
    at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler.invoke(JAXRPCHandler.java:152)
    at com.ibm.ws.webservices.engine.handlers.WrappedHandler.invoke(WrappedHandler.java:64)
    at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:228)
    at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:228)
    at com.ibm.ws.webservices.engine.WebServicesEngine.invoke(WebServicesEngine.java:336)
    at com.ibm.ws.webservices.engine.transport.http.WebServicesServlet.doPost(WebServicesServlet.java:831)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
    at com.ibm.ws.webservices.engine.transport.http.WebServicesServletBase.service(WebServicesServletBase.java:341)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1103)
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:570)
    at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:486)
    at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3440)
    at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267)
    at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:815)
    at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1461)
    at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:118)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
    at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
    at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
    at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
    at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
    at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
    at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
    at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
    at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
    at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)
    Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Priority
    at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402)
    at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347)
    at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:597)
    ... 62 more

    Thanks,