Servlet 2.3 Class Loading Module Used by Default

The default class loading model in the web container has been changed to use the standard servlet model that isolates the wars from other deployments, and loads classes/resources preferentially from the war. In addition the, classes from packages that cannot be overriden due to their use in the web container are simply ignored. An example is the commons logging packages. Prior to 4.0.2 a removal of such packages had to be removed from the war.

The changes are detailed in JBAS-1691 along with how the previous class loading behavior can be restored.

Using JDK5 Features in JSP Pages

Tomcat 5.5 uses the eclipse jdt compiler and this currently does not support java5 features. To revert to the jdk javac compiler:

1. Remove or rename the jbossweb-tomcat55.sar/jasper-compiler-jdt.jar. A name like jasper-compiler-jdt.jar.bak will avoid adding the jar to the tomcat classpath.

2. Drop a recent ant.jar into the jbossweb-tomcat55.sar directory. I tested with the ant-1.6.3 jar.

3. Edit the jbossweb-tomcat55.sar/conf/web.xml jsp servlet to include the following compilerSourceVM/compilerTargetVM params:

   <servlet>
      <servlet-name>jsp</servlet-name>
      <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
      <init-param>
         <param-name>fork</param-name>
         <param-value>false</param-value>
      </init-param>
      <init-param>
         <param-name>xpoweredBy</param-name>
         <param-value>false</param-value>
      </init-param>
      <init-param>
         <param-name>compilerSourceVM</param-name>
         <param-value>1.5</param-value>
      </init-param>
      <init-param>
         <param-name>compilerTargetVM</param-name>
         <param-value>1.5</param-value>
      </init-param>

Tomcat Valve Changes

If you have implemented tomcat specific integration valves, they need to be updated for api changes in the tomcat 5.5 Valves api. The following jboss-4.0.1/tc5.0

package some.pack;

import java.io.IOException;
import java.security.Principal;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.catalina.Request;
import org.apache.catalina.Response;
import org.apache.catalina.ValveContext;
import org.apache.catalina.Wrapper;
import org.apache.catalina.Session;
import org.apache.catalina.Manager;
import org.apache.catalina.valves.ValveBase;

public class MyValve extends ValveBase
{
   public void invoke(Request request, Response response, ValveContext context)
           throws IOException, ServletException
   {
      // Get the request caller which could be set due to SSO
      HttpServletRequest httpRequest = (HttpServletRequest) request.getRequest();
      Principal caller = httpRequest.getUserPrincipal();
      HttpSession hsession = httpRequest.getSession(false);

      ...
      // Perform the request
      context.invokeNext(request, response);
   }
}

would have the jboss-4.0.2/tc5.5 changes:

package some.pack;

import java.io.IOException;
import java.security.Principal;
import javax.servlet.ServletException;
import javax.servlet.http.HttpSession;

import org.apache.catalina.Session;
import org.apache.catalina.Wrapper;
import org.apache.catalina.Manager;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.valves.ValveBase;

public class MyValve extends ValveBase
{
   public void invoke(Request request, Response response)
           throws IOException, ServletException
   {
      // Get the request caller which could be set due to SSO
      Principal caller = request.getUserPrincipal();
      HttpSession hsession = request.getSession(false);

      ...
      // Perform the request
      getNext().invoke(request, response);
   }
}

Hibernate Deployer

See Hibernate3 Issues for issues regarding changes in the har deployer.

Commons Logging

The default server configuration lib directory now includes commons-logging.  By default this jar is used even when UseJBossWebLoader=false.  If you include commons-logging with your deployment you may have conflicts that did not exist when deploying on earlier releases under the default server configuration.

SecurityAssociation Changes

The SecurityAssociation is an internal api subject to change at anytime. If you are integrating at this level your code is tied to jboss specific details that can change even between minor releases. The 4.0.2 release introduced such a change to propery deal with nested run-as calls. The primary incompatibility is that the SecurityAssociation.getSubject has a very limited scope, and is generally unreliable.

To gain access to the authenticated Subject requires that integration directly after the security interceptor which established the authentication. The preferred way of accessing the subject is to use the JACC PolicyContext API:

import javax.security.auth.Subject;
import javax.security.jacc.PolicyContext;
import javax.security.jacc.PolicyContextException;

   /** The JACC PolicyContext key for the current Subject */
   private static final String SUBJECT_CONTEXT_KEY = "javax.security.auth.Subject.container";

         Subject caller = caller = (Subject) PolicyContext.getContext(SUBJECT_CONTEXT_KEY);

If you are using the AuthenticationManager.isValid call directly, you need to use the form that passes in a subject:

   AuthenticationManager securityManager = ...;
   Subject subject = new Subject();
   if (securityManager.isValid(principal, credential, subject) == true)
   {
      // subject has the login module associated info
   }