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:

PLAIN TEXT
XML:
  1. <html>
  2.    <head>
  3.       <title>500 Internal Server Error</title>
  4.    </head>
  5.    <body>
  6.       <h1>500 Internal Server Error</h1>
  7.       <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>
  8.    </body>
  9. </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:
OC4J Deployment screen

and
OC4J Deployment

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 :-)