There are some annoying problems with WAS 5.0 and Cocoon 2.0x (Cocoon 2.1 not tested yet). After some research in various newsgroups and greping the Cocoon Dev. list I found this and this. Here the aggregation of the solutions:

1.) Make sure that the application server classloader is set to MODULE visibility. Then set the ClassLoader on the ear to PARENT_LAST and then again, set the ClassLoader on the war module to PARENT_LAST. This has the effect, that WebSphere does not override the Cocoon ClassLoader (Don't forget to delete the server's temporary cache if you have run without the ClassLoader set as above).

2.) The most stupid problem are the broken HTTP redirects. According to the Cocoon dev. list WebSphere violates the page 76 of the Servlet 2.3 specification.

Example when you have a mapping like this:



and you request http://localhost/MyWebApp/stupid/servlet/spec, then request.getServletPath() should return /stupid/servlet/spec, but WebSphere is returning /, which is IMHO wrong and this breaks Cocoon.

A workaround for this is to do

{{{<map:match pattern="document/index">

instead of

{{{<map:match pattern="documents/index">

which resolves the path completly.

I will do some more tests with the fixpacks 1 and 2 of WAS 5.0. In the moment I don't get any of the fixpacks installed on my Red Hat 9.0 box.

Maybe this bug is fixed in some of those fixpacks. If not I will open a WebSphere PMR (defect). I can do this.

Two hours later:
WebSphere 5.0.1 has the same problem with request.getServletPath().

One day later:
Still no success to apply any of the fixpacks on Red Hat 9.0. Anyway, I just opened a PMR for this request.getServletPath() problem. Let's wait and see.

Feel free to add your comments below. --GerhardFroehlich

These tips work also for Cocoon 2.1 . I had just a problem with the apache axis stuffs, do not know why. I just removed axis from cocoon.xconf and everything else seem to work fine. --AlexandreVictoor

October 11th 2004:

Unfortunately there are some annoying problems with WAS 5.1 and Cocoon as well. A solution should be like this:

The invokes the (HttpServletResponse implementation) retrieving the correct servlet path, appends it in the redirect uri

There need to add into the web.xml file the following configuration: {{{<filter>

</filter> <filter-mapping>

</filter-mapping> }}}


WebSphereV5.0Deployment (last edited 2009-09-20 23:41:33 by localhost)