It turns out that WebSphere isn't properly honoring the Servlet load-on-startup setting. The side effect of this is that the SpringWebflowInstantiationServlet (hereafter: SWfIS) isn't being loaded prior to the PersistentFacesServlet, and the SeamUtilities class that is attempting to determine if Spring is present is failing. I'm not sure what the actual result of this is, there are a few places where decisions are made using the Spring flag, but it's safe to say this application wont work if this flag is wrong.

It's apparent that the code in SeamUtilities is misplaced, and that the detection of whether Spring is present belongs in the SWfIS. In WebSphere it is eventually loaded, and it could set a flag in SeamUtilities (in order to minimize the API disruption the isSpringEnvironment method should remain in SeamUtilities) when it is loaded.

For the purpose of this customer, it's simple enough to remove part of the test on line 504 of SeamUtilities:

try

catch (Throwable t) {
if (log.isDebugEnabled())

}
if (null != springClass && springWebFlowConfigured() ) { <---------------------- Line 504
springLoaded = 2;
if (log.isDebugEnabled())

}

To this:

if (null != springClass ) { <---------------------- Line 504
springLoaded = 2;

That allows the Spring detection code to work as required.

A follow up issue had the icefaces buttons not working. It looked like the external context wasn't keeping track of the fact that redirection had been requested, but the customer has reported that another Class loading issue is preventing a isJSF12 flag from being set. This flag changes the way the request maps are handled and would affect whether ICEFaces detects a request as a Spring request.

It's not clear why this Class isn't available for class loading at startup.

To temporarily get them working, the following lines of code may be used to hardcode JSF1.2 detection. They would replace lines 114 -> 151 in com.icesoft.faces.webapp.parser.ImplementationUtil.java. I've added a few lines of system outs for the code, there is java logging in place but sometimes getting output can be troublesome in WebSphere.

//Test for JSF 1.2 <-- line 114
try

catch (Throwable t)

System.out.println("__ Setting JSF12 to true for patch __");
isJSF12 = true;

if (log.isTraceEnabled())

//Test for JSF 2
try

catch (Throwable t)

if (log.isTraceEnabled())

try

catch (ClassNotFoundException e) {
}

if (log.isTraceEnabled())

// < - line 151

i've checked in a general purpose change for the code, allowing a context param

com.icesoft.faces.forceJSF12

To be defined with a boolean parameter that overrides the classloading detection. Oddly, in my test, the value of this flag could not be read (despite being readable in the auctionMonitor application), so if this is important, the following logging conditions exist:

try {
String value = ec.getInitParameter(FORCE_JSF12);
if (value != null && !"".equals(value))

else

} catch

If this block isn't working, turn on debug level logging in WebSphere and check to see that the parameter is read correctly. It may be that the parameter isn't read if I just change web.xml in the exploded installed directory of websphere.

I'm almost positive there will be other shoes to fall on this one. This type of classloading behaviour can't be good.

WebSphere does provide a ClassLoader Viewer tab in its management console. It appears (to my untrained eye) that all the jars in the WebApplication are on the WAS Module classpath. In the entire WebSphere installation directory, there is only one version of the javax.faces.webapp.UIComponentELTag class (in the correct place btw). That this code can't classload this class seems really odd to me at the moment.

I have changed the code in SeamUtilities so that instead of calling a getter on the SpringWebflowInstantiationServlet to fetch the flag, the SpringWebflowInstantiationServlet can now call a static setter on the SeamUtilities class. This prevents the order of operations error seen before. It's true that the SeamUtilities class is still loaded through a call chain from one of the other servlets, but I added a call to re-evaluate the Spring settings on startup and this works in WebSphere where we were having the problems.