JHeadstart Blog

While deploying your JHeadstart application to OC4J 10.1.3.2 or higher, are you experiencing error messages like the following?

• Operation failed with error: org/apache/log4j/Category
• No appenders could be found for logger (com.sun.faces.config.ConfigureListener)
• oracle.oc4j.admin.internal.DeployerException: java.lang.ExceptionInInitializerError
• org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;@900079 for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)

This occurs because OC4J 10.1.3.2 and higher has defined a common shared library for apache.commons.logging, but this library has a dependency on log4j classes, which are not available in that shared library. Having log4j.jar in your EAR file does not help, because when called from a shared library, the classloader expects them to be available in the shared classpath instead of in the application-specific classpath. See OC4J bug 5871305 and Note 460448.1 in MetaLink for more information.

The workaround is to exclude apache.commons.logging from the shared library for your application: update orion-application.xml with the lines

<imported-shared-libraries> 
  <remove-inherited name="apache.commons.logging"/> 
</imported-shared-libraries>

Then create a JDeveloper deployment profile as follows:

1. Run the ADF Runtime Installer
   
2. In the ViewController project,
   create a new WAR Deployment Profile (File | New | General | Deployment
   Profiles | WAR File).
3. In the deployment profile properties, go
   to WAR Options, and select Compress Archive.
4. If you
   use Subversion,
   go to all Filters categories, then to Patterns, and exclude **/.svn/

Farbod posted his solution to deploying a JHeadstart application from JDeveloper 10.1.3.3 to OC4J 10.1.3.3 on the JDeveloper OTN Forum. Check out his steps to successfully deploy a JHeadstart application.

If you get an error

java.lang.IllegalStateException: AdfFacesContext was already released or had never been attached.

while the underlying error is something else, then check your web.xml. Do you have the following filter mapping?

    <filter-mapping>
        <filter-name>adfFaces</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>

Then remove or comment out this mapping. This results in seeing the original stack trace if a runtime problem occurs. However, it also means that you will get runtime warnings like

WARNING The AdfFacesFilter has not been installed. ADF Faces requires this filter for proper execution.

If these warnings are caused only by removing this particular filter mapping, you can safely ignore them. You probably have filter mappings to the AdfFacesFilter for *.jsp and *.jspx, which takes care of applying the filter at the appropriate time. Having these runtime warnings is better than not seeing the underlying error in case of a problem!