Raible's Wiki

Raible Designs
Wiki Home
Recent Changes


  - Korean
  - Chinese
  - Italian
  - Japanese

QuickStart Guide
  - Chinese
  - French
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish
  - Japanese

User Guide
  - Korean
  - Chinese

  - Chinese
  - German
  - Italian
  - Korean
  - Portuguese
  - Spanish

  - Korean

Latest Downloads

Other Applications

Struts Resume
Security Example
Struts Menu

Set your name in

Edit this page

Referenced by

JSPWiki v2.2.33


Hide Menu


Steps for running Appfuse 1.8.2 under Oracle Application Server Enterprise Edition 10g Release 2 (

Contributed by Stefano Bertini (stefano.bertini at plangroup.it)

To successfully deploy an application developed with Appfuse 1.8.2 under the Oracle AS 10g Rel.2 there are quite a number of steps to follow as Oracle AS has a lot of different (and odd) behaviours from Tomcat.

We need to modify the build.xml and some classes...
And we need to write some new ones...

Here we go !

Oracle doesn't like tags in web.xml

We need to edit the properties.xml file to add a property:

<property name="DeployOnOrion" value="true"/>

Then, we modify the build.xml, in the package-web target so that it doesn't remove the comments from the tags:

    <and>    <!-- Modified Part start -->
        <isset property="DeployOnOrion"/>
      <isset property="tomcat5"/>
      <isset property="tomcat5.5"/>
    </and>   <!-- Modified Part end-->
      <replaceregexp flags="g"
      <replaceregexp flags="g"

The contextConfigLocation parameter

In the /metadata/web/web-settings.xml file there is the contextConfigLocation parameter that looks like this:


The problem with Oracle AS is that the wildcards syntax won't work.
And, moreover, the classpath*:META-INF/ search doesn't work because Oracle returns a bad URL format while browsing inside jar files.

So we have to do two different things: the first step is to modify the build.xml file so that it copies the applicationContext-hibernate.xml and applicationContext-service.xml files in the WEB-INF directory.
We do this by adding the following statements at the end of the copy-resources target:

  <copy overwrite="true" tofile="${build.dir}/${webapp.name}/WEB-INF/applicationContext-${dao.type}.xml">
    <fileset dir="src/dao" includes="**/*-${dao.type}.xml"/>
    <filterset refid="variables.to.replace"/>
  <copy tofile="${build.dir}/${webapp.name}/WEB-INF/applicationContext-service.xml">
    <fileset dir="src/service" includes="**/*-service.xml"/>

Then, we modify the contextConfigLocation parameter in this way:

Oracle calls the UserCounterListener twice

The UserCounterListener is added twice when the application is deployed because it is defined both in the web.xml file and in the /WEB-INF/.tld file.

This causes the application to add every user twice in the user list.

Infact, the webdoclet target, in the jsptaglip subtask, re-adds every listener in the taglibrary definition.

You need to modify the webdoclet target in this way:

  <target name="webdoclet" depends="compile-web" unless="webdoclet.unnecessary"
    description="Generate web and Struts descriptors">
    <taskdef name="webdoclet" classname="xdoclet.modules.web.WebDocletTask">
          <path refid="xdoclet.classpath"/>
          <path refid="web.compile.classpath"/>
    <webdoclet destdir="${webapp.target}/WEB-INF"
      <fileset dir="src/web"/>
      <fileset dir="${build.dir}/web/gen"/>
      <deploymentdescriptor validateXML="true"
        servletspec="2.3" sessiontimeout="10"
        destdir="${webapp.target}/WEB-INF" distributable="false"
        <configParam name="httpPort" value="${http.port}"/>
        <configParam name="httpsPort" value="${https.port}"/>
        <configParam name="daoType" value="${dao.type}"/>
     <strutsconfigxml validateXML="true" version="1.2"/>
    <webdoclet destdir="${webapp.target}/WEB-INF"
       <fileset dir="src/web" excludes="**/listener/**"/>
       <fileset dir="${build.dir}/web/gen"/>
       <jsptaglib validateXML="true"
         description="Custom tag library for this application"
         shortName="${webapp.name}" filename="${webapp.name}.tld"/>

When invalidating a session, Oracle doesn't call any HttpSessionAttributeListener

So the UserCounterListener is never called to remove unlogged users from the User List.

To fix this behaviour I created an OrionSessionListener class that gets called when a session is invalidated and that removes every variable in the session itself, forcing every HttpSessionAttributeListener to be called from the server.

Here is the class (create it in your /src/.../webapp/listener directory):

  package <your_package_path>.webapp.listener;
  import java.util.Enumeration;
  import javax.servlet.http.HttpSession;
  import javax.servlet.http.HttpSessionEvent;
  import javax.servlet.http.HttpSessionListener;

   * This listener is invoked by Orion when a session is invalidated.
   * It removes every variable bound to that session forcing Orion
   * to call every HttpSessionAttributeListener. 
   @author <a href="mailto:stefano.bertini at plangroup.it">Stefano Bertini</a>
   * @web.listener
  public class OrionSessionListener implements HttpSessionListener {
    public void sessionCreated(HttpSessionEvent event) {
    public void sessionDestroyed(HttpSessionEvent event) {
      HttpSession session = event.getSession();
      Enumeration names = session.getAttributeNames() ;
      while (names.hasMoreElements()) {

Null Object reference in class ConstantsTag

In the header.jsp page, you get a NullPointerException when executing the line

  <appfuse:constants scope="request"/>

This is caused by the release() method of the ConstantsTag

  public void release() {
      clazz = null;
      scope = Constants.class.getName();
in the line
  clazz = null;

Just comment it out and everything works again.

I tried to use the class parameter of the constants tag, but i got another error and i had no more time to investigate further. :-)

Oracle doesn't execute filters if the url doesn't contain an extension

The problem happens with the j_security_check filter.

If you deploy the application, you will find out that it is impossible to login. This happens because the filter that should be triggered by the j_security_check url never gets called.

I found out that the problem is because the url doesn't have an extension, so I changed the j_security_check into j_security_check.login and everything works again.

You have to change this in the following files:

Strange behaviours with Orache Web Cache

Using Oracle Web Cache i noticed some strange behaviours. OWC keeps caching pages even if the header's meta tags say not to cache anything.

I had to disable the OWC to have the application work correctly.

Go to top   Edit this page   More info...   Attach file...
This page last changed on 06-Nov-2006 13:53:00 MST by unknown.