Tuesday, September 9, 2008

Grails 1.0.3 and BEA/Oracle Weblogic 10

by Richard Vowles

So I am working on a project that is using Oracle/BEA Weblogic 10 and we have been having really big problems trying to get a Grails 1.0.3 application deployed successfully on it.

It uses Apache CXF as its web services layer as well, which makes it even more tedious. So the lessons we learnt?

Weblogic hates non-serialable objects in its web Session object

Grails domain objects when they have constraint violations store themselves into the web Session and this creates problems for Weblogic as the objects are (a) not serializable by default, (b) any closures in them are not transient by default (e.g beforeInsert closures) and (c) links to Services often cause problems. We didn't have (c) (it is logged in the GRAILS bug parade).

class Order implements java.io.Serializable {
def transient beforeInsert = {
// do thing
}
}

All objects referenced by your class also need to be tagged thus as well.

Weblogic has to be told to tow the line for classes

<weblogic-web-app>
  <context-root>/wls_app</context-root>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
<charset-params>
<input-charset>
<resource-path>/*</resource-path>
<java-charset-name>UTF-8</java-charset-name>
</input-charset>
</charset-params>
</weblogic-web-app>

We didn't end up having to deploy it as a EAR file.

CXF just wouldn't work unless....

We are using the web security handler and that creates a SAAJInInterceptor. That SAAJInInterceptor would always pick up weblogic one, and so we had to get the source code to both the WSS4JInInterceptor and the SAAJInInterceptor and force system properties to make them use the CXF implementations. Thank goodness for open source!

Weblogic 10 has a bug in its handling of the Content-Type field

The requirement under RFC 1521 is that Content-Type should look like:

Content-Type: type/type; param=value; param-value; etc

Under Weblogic, once charset= is found, it uses the entire rest of the line to attempt to set the charset! Under normal SOAP usage, this will also include the SOAP's action so the char set was (in our case) something like UTF-8;action="/blah/blah/blah" - which of course wasn't being handled properly.

So thats it. I think.

No comments: