It’s Only Software

If you have done Websphere Portal 5.1 development, you have probably seen this error (among many others) at some point in your development lifecycle:

EJPPG0003E: ServletContext lookup for /.MyPortalApp returned the portal context. It has to be a different one.

Let me tell you that this error can be caused by about a hundred different things. If the issue is actually a context issue, you can follow Jamie Mcllroy’s great instructions to try to resolve context root-type problems.

But let’s say you do that, and you’re still getting the error - what then? (I’m assuming, by the way, that you are running inside RAD with the Websphere Portal UTE.)

As near as I can figure out, this error is thrown when you try to access a portlet and the backing application (usually a WAR within an EAR) doesn’t initialize itself properly. If you read into this, it basically means this error can be caused by a wide variety of issues with the underlying application.

First, make sure that you have console logging enabled in your server configuration. To do this, open your server configuration, click on the “Portal” tab (far right), and ensure the “Enable console logging” box is checked.

Next, when you attempt to access your portlet, you should (hopefully!) see an error appear in the console log. If you do, have a look at it, and hopefully it will be obvious what’s wrong.

If it’s not obvious, or if you get the infamous PortletExeption, you may have to enlist the help of a debugger. I would suggest the following steps:

1. Restart the server in Debug mode
2. When the server starts up, set a Java Exception Breakpoint for Throwable
3. Attempt to hit the offending servlet or portlet

If the servlet is throwing an error that ends up being reported as EJPPG0003E, you’ll see the debugger stop at the exception in question. I personally have seen this error caused by various JSF configuration errors (with portlets using JSF), and classloader issues (missing MANIFEST.MF entries, classloader configuration issues, PARENT_LAST vs PARENT_FIRST, etc).

Hope this helps someone! If you have any other suggestions for diagnosing this error, please share!

I guess I’ve had a busy / buggy weekend noodling around with stuff. I ran into a [known] bug in the latest JSTL/JSF 1.2 Reference Implementation on Tomcat 6.0.14.

I was playing around with Spring MVC 2.5.1, and even the simplest JSP page gave me this:

java.lang.NullPointerException
	com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:312)
	com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:87)
	com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:240)
[snip]

This is interesting, because I wasn’t even using JSF!

It turns out that there’s a bug that is lightly documented in the JSTL/JSF 1.2_07 RI release notes:

There is a chance for an NPE in com.sun.faces.application.WebappLifecycleListener with some configurations (see issue 670). Take for example, installing JSF in a container such that JSF will be available to all web applications. The NPE will occur for an application that doesn’t have the FacesServlet defined within it’s web.xml.

The workaround for this issue is, within the global web.xml for the container (JBoss and Tomcat both have one) add either a FacesServlet definition (no mapping) or add the context init parameter, com.sun.faces.forceLoadConfiguration, with a value of true. NOTE: GlassFish is not affected by this issue.

This is also covered in the Mojarra bug database as bug 670, and the JBoss bug database as bug JBAS-5063.

There’s some discussion in this JBoss forum thread indicating how to solve for JBoss AS, which is a good start.

For Tomcat 6, you can add the following to context.xml:

	<Parameter name="com.sun.faces.forceLoadConfiguration" value="true"/>

One caveat here is if you’re running an Eclipse-based Tomcat instance. Eclipse-configured Tomcat doesn’t have an easily accessible context.xml. Instead, you’ll have to configure this in the global default webapp. Look in your Eclipse workspace for the server configuration (by default, Eclipse will put this in a top-level project called “Servers”).

In the web.xml you’ll find in there, add the following:

 <context-param>
  <param-name>com.sun.faces.forceLoadConfiguration</param-name>
  <param-value>true</param-value>
 </context-param>

This should not be put in your web application’s web.xml!

Once you do this, you should not receive the NullPointerException upon first access to a JSP. It looks like this bug will be fixed in the next RI release of JSF/JSTL.