For my current project I am migrating several projects from JDeveloper 10.1.3.1 to JDeveloper 10.1.3.3. After migrating my WebService project I deployed the application to my local Standalone OC4J instance and ran my test suite in SoapUI to test the migrated services. But to my surpise, all requests failed! They all gave the same response:
<html>
<head>
<title>500 Internal Server Error</title>
</head>
<body>
<h1>500 Internal Server Error</h1>
<pre>Servlet error: An exception occurred. The current application deployment descriptors do not allow for including it in this response. Please consult the application log for details.</pre>
</body>
</html>
Although the web services were generated with JDeveloper’s Web Service ‘wizard’ (one way to create a web service which I definitely don’t like), it just could be that I had to recreate them with the newer JDev version.
But before I took that approach, I had a look in the ‘application.log’ file to see if there was some more info there. And yep, there was:
08/06/27 12:40:02.547 MyWS: Servlet error
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
….
….
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@dc5c99 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@dc5c99 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at net.pascalmalma.ws.base.BaseService.(BaseService.java:26)
… 34 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@dc5c99 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
… 38 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
at java.lang.Class.getConstructor0(Class.java:2640)
at java.lang.Class.getConstructor(Class.java:1629)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
… 39 more
It seemed I (suddenly??) had some conflicting issues with commons-logging. So now I only needed to solve this issue… One hour later and having shifted the libraries throughout almost every directory in OC4J, I just gave up to look for a ‘nice’ shared configuration (as is described here).
I went for the quick (and dirty??) solution which means disabling the use of the shared libraries for log4j and supply the necessary libraries (commons-logging and log4j) with each web application deployment. You can set the option in the OC4J Enterprise Manager, like this:
and
Only disadvantage is that if you deploy your application directly from JDeveloper this property is overwritten and the issue is back again…. Luckily I found this entry of the JHeadstart team. It appears they had the same problem, but this makes my life somewhat easier 🙂
The Pragmatic Integrator 
This is because of a jar conflict between the two copies of apache-commons-logging jar(one within the server’s shared library & other within the application)
There is another alternative:
In case of web application,
create a orion-webapp.xml as follows and place it within WEB-INF folder
****************************************************
**********************************************
This will make use of the apache-commons-logging jar within the application and hence resolve the error.This is particularly helpful when using automated build & deployment thru ant scripts as it avoids the manual activity of unchecking the checkbox.
orion-web.xml
****************************************************
**********************************************
Sorry the orion.xml file is not getting dispalyed.Just copy a orion-web.xml from any of the deployed applications within the server and uncomment the section containing search-local-classes-first=”true” attribute