I have two Applications Installed on Websphere Server v.6. 1. SGOApplication 2. ReportingWeb
SGOApplication has a shared library mapped on Application Level i.e. SGOAPPSHLIB
This library is having a logging framework jar(logsrv.jar). There is a class in logsrv.jar called SLEEventLogger which logs the messages to a file and uses some other third party classes which are all bundled in logsrv.jar
I want to use logsrv.jar for ReportingWeb Application. I made a call for SLEEventLogger class from another class in ReportingWeb. I was able to build the ear and deploy it as logsrv.jar is there in the build path.
After that, I tried following things, but none of them worked.
- Mapped SGOAPPSHLIB on Application level for ReportingWeb Application. Used application class loader first policy.
- Created a new Shared library REPSHLIB and put logsrv.jar in it. Mapped this library with application.Used application class loader first policy.
- Mapped REPSHLIB on server level. THIS WORKED for REPORTINGWEB Application but other Application SGOApplication is not able to find the class now.
I am getting ClassDefNotFoundException: com.statestreet.framework.logging.SLEEventLogger when trying to run webapplication and control reached that particular class where I used SLEEventLogger.
I tried to search for SLEEventLogger class from Troubleshooting>Classloader in websphere Console. I was able to find that SLEEventLogger class is being loaded by Module Class Loader.
How to resolve this issue? I tried so many permutations and combinations on the server configuration but with no luck. I am totally开发者_运维百科 messed up with this.
To make this work you should:
- Add logsrv.jar to the WebSphere classloader using the ws.ext.dirs property
- Remove logsrv.jar from the application and modules classloaders (ie including removing it from
WEB-INF/lib
)
I think that you might have done part (1) in your third attempt, ie when you mapped REPSHLIB on server level. That's why it worked for ReportingWeb. I guess that the reason it broke in SGOApplication is because SGOApplication probably already has a copy of logsrv.jar — that extra copy could conflict with the one loaded by the WebSphere classloader. The key is to make sure that only one copy of the JAR is in any of the classloaders.
See http://www.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html#N100F8 for a nice diagram of WebSphere's classloader hierarchy.
This exception means that some class that com.statestreet.framework.logging.SLEEventLogger depends on, cannot be found. Meaning: the class com.statestreet.framework.logging.SLEEventLogger is found. But it depends on something that cannot be found, therefore it cannot be loaded. If you have sources, you can easily find all classes com.statestreet.framework.logging.SLEEventLogger uses (just see imports). Otherwise, you can try to decompile.
I suggest DEBUG logging be enabled to give you a clearer picture of what is happening in your application.
Of course, you mentioned that your logsrv.jar file was in your build path. It's worth noting that build path and your application's classpath may not in fact be one in the same.
According to the documentation for the NoClassDefFoundError exception, it's thrown when a class "existed when the currently executing class was compiled, but the definition can no longer be found."
In other words, the SLEEventLogger class was in your build path, allowing your application to compile, but the exception suggests that the JAR file containing this class is most likely not in your classpath.
When you try to run the application, the class that was compiled with knowledge that SLEEventLogger exists can no longer find it; as a result, a NoClassDefFoundError exception is thrown.
http://download.oracle.com/javase/1.4.2/docs/api/java/lang/NoClassDefFoundError.html
精彩评论