JHeadstart Blog

If you want to deploy a JHeadstart 10.1.3 application to an
application server that uses JDK 1.4 (like Oracle Application Server
10.1.2), you need to build your application with JDK 1.4. By default,
JDeveloper 10.1.3 uses JDK 1.5.



To prepare for this, there are two things you should do early in the development process:

1. Generate your JHeadstart application with Server level property JSP Version = 1.2 in the Application Definition
   
   


2. In both Model and ViewController project, go to Project Properties, Compiler, and set Source and Target to 1.4

In the earlier post If you intend to deploy JHeadstart 10.1.3 to OracleAS 10.1.2 I explained which preparation steps to take if you are going to deploy your JHeadstart 10.1.3 application to an
application server that uses JDK 1.4 (like Oracle Application Server
10.1.2). I promised that in a later post I would blog about how to do the actual deployment.

Well, here it is! Below are the steps I took to successfully deploy a JHeadstart 10.1.3 application to Oracle AS 10.1.2 (after trying out several other methods). The steps are so generic that I think they can be used for any JDeveloper 10.1.3 web application using ADF Business Components and JSF or ADF Faces.

1. Create a new OC4J Instance in OracleAS 10.1.2 (for example from the Application Server Home Page).
2. Disable ADF Runtime for this OC4J instance by modifying its [OC4JInstanceHome]/config/application.xml (on the file system of the application server machine). Comment out the following lines:
   

<library path="../../../BC4J/lib"/>
<library path="../../../jlib/ojmisc.jar"/>
<library path="../../../ord/jlib/ordim.jar"/>
<library path="../../../ord/jlib/ordhttp.jar"/>
<library path="../../../jlib/jdev-cm.jar"/>

and


<library path="../../../uix/taglib"/>

3. If necessary, set up Data Sources and other configuration settings for OC4J.
4. In the ViewController project properties, go to Libraries.
   
5. Add the following libraries that are needed for the Model project:
      BC4J Oracle Domains
      Oracle JDBC
      SQLJ Runtime
6. Also add or create any other libraries where needed to get the right jar files in the EAR file.
   
7. In the ViewController project, create a new WAR Deployment Profile (File | New | General | Deployment Profiles | WAR File).
8. In the deployment profile properties, go to WEB-INF/lib Contributors, and select all the libraries (except JSP Runtime).
9. In the deployment profile properties, go to WAR Options, and select Compress Archive.
10. If you use Subversion, go to all Filters categories, then to Patterns, and exclude **/.svn/
11. In web.xml, replace

<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"  
version="2.4"  
xmlns="http://java.sun.com/xml/ns/j2ee">

by

<!DOCTYPE web-app PUBLIC  
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"  
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>

12. On your development PC, install JDK 1.4 (for example, copy the jdk folder from a JDeveloper 10.1.2 home).
13. In the ViewController Project Properties, go to Libraries.
14. Click the Change button for the J2SE Version.
15. Click the New button to create a new J2SE Definition.
16. Browse to your [JDK1.4Home]/bin/java.exe for the J2SE Executable.
17. When asked to install OJVM, click OK.
18. Accept the default settings for name, class path, source path, and doc path.
19. Choose if you want to define the new J2SE definition at Project level (every deployer needs to have JDK 1.4 in same path), or User level (every deployer needs to create own J2SE definition).
20. Save the settings.
    Warning: after this step (usage of J2SE 1.4), do not try to run Embedded OC4J (see below how to enable Embedded OC4J again).
21. In the Model Project Properties, do the same (define a similar J2SE 1.4 Version).
    
22. Empty your classes folder (the output directory for the compiler). You can do that in JDeveloper via the menu option Run - Clean ViewController.jpr.
    
23. Right-click the deployment profile and choose Deploy to EAR. The log tells you where it creates the EAR file.
    
24. Deploy the EAR file to the new OC4J instance (see this documentation).
    

• In both the Model and the ViewController Project Properties, go to the Libraries page, and change the J2SE Version to 1.4 (which is now already defined).
• Empty your classes folder (the output directory for the compiler). You can do that in JDeveloper via the menu option Run - Clean ViewController.jpr.
• Right-click the deployment profile and choose Deploy to EAR.
• Deploy the EAR file in the new OC4J instance.
• Change the J2SE Version back to 1.5 (in both Model and ViewController).

Oscar writes in to ask if he can deploy JHeadstart on a BEA WebLogic application server instead of an Oracle Application Server. The answer is yes:  a JHeadstart application is "just" an ADF application, and therefore is compatible with all application servers mentioned in the JDeveloper Application Server Support Matrix.

You can deploy a JHeadstart / ADF application to:

• Oracle Application Server
• Standalone OC4J
• Tomcat
• JBoss
• WebLogic
• WebSphere

Xavier found out how to deploy his JHeadstart 10.1.2 application to Oracle Application Server 10.1.3, so I'd like to share it with you.

He followed the instructions in Ric Smith's Deploying a 10.1.2 UIX Application to a 10.1.3.x OC4J Instance. When running the application, he got an error:

java.lang.NullPointerException
at oracle.jheadstart.controller.AuthenticationFilter.doFilter (AuthenticationFilter.java:182)

The problem was caused by the AuthenticationFilter being called for requests where the ADFBindingFilter was not called. The ADFBindingFilter takes care of creating a new HttpSession, and if this is not done you get the NullPointerException.

This can be solved by changing the WEB-INF/web.xml file. The filter mappings for the AuthenticationFilter (and the CharacterEncodingFilter) should be similar to those of the ADFBindingFilter:

  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <url-pattern>*.jspx</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>action</servlet-name>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>uix</servlet-name>
  </filter-mapping>
  <filter-mapping>
    <filter-name>ADFBindingFilter</filter-name>
    <servlet-name>ordDeliverMedia</servlet-name>
  </filter-mapping>

So remove the existing filter mappings for AuthenticationFilter and CharacterEncodingFilter, and copy the above filter mappings instead while replacing ADFBindingFilter by AuthenticationFilter and CharacterEncodingFilter respectively.

That should do the trick. Thank you, Xavier!

OC4J 10.1.3 allows you to include Data Source definitions with your EAR file. JDeveloper 10.1.3 automatically creates such EAR Files if you deploy to Oracle Application Server 10.1.3. But what if you don't want to include the database connect information in your EAR file?

In my opinion, data sources are useful for externalizing the database connections (development, test, production, ...) from the web application. I think it's best to use the same EAR file for all environments, and have different data source definitions in each environment. The data sources should have the same name of course, but connect to different databases.

In JDeveloper 10.1.3 I had defined an Application Server connection to our Development OC4J 10.1.3 instance, and discovered that the EAR files I created with JDeveloper deployment profiles always included data source definitions. That meant that I had to change the data sources in the Test and Production application servers after deploying this EAR file.

Fortunately, I also found a way to omit the data sources from the EAR file: remove all Application Server Connections from your JDeveloper 10.1.3 installation before creating the EAR file using a deployment profile. JDeveloper then cannot determine the type of application server you deploy to, and will not include the data source definitions.

Then it became much easier to use the same EAR file for all environments!

Cliff Cotino had a good tip on the JHeadstart Discussion Forum: how to show the complete error in case your deployed application shows only a 500 Internal Server Error.

Suppose your application runs fine in Embedded OC4J in JDeveloper, but when deployed on Standalone OC4J or Oracle Application Server shows this error:

500 Internal Server Error

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.

If you want to know the complete error message and stack trace you must deploy the
application in "development" mode. To achieve this you must perform the following:

Suppose you have a JDeveloper Application Server connection named "ConnectionName".

• Right-click the deployment profile and select "Deploy to ConnectionName"
• In the "Configure Application" dialog box you have the option to edit certain deployment options.
• Select the web-app on the left side of the screen. On the right side of the screen there is an option "development". Set the value to "true" and deploy your application.
  

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)

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

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/

If you are having trouble deploying a JHeadstart ADF application developed with JDeveloper 10.1.3 to OC4J 10.1.2, then you can also try to install OC4J 10.1.3 under your Oracle Application Server 10.1.2.

Alternatives are described in earlier JHeadstart blog posts, see the Deployment category.