Caffeine Induced

Here are the things that caused problems :

1. Some of the JBoss client jars were reorganized / renamed (e.g. jaas.jar -> jboss-jaas.jar, jmx-rmi-adaptor.sar -> jmx-adaptor-plugin.jar). We have a Swing client (launched through webstart) and a web based client. For the webstat app, we have to sign all the jars (and list all the jars in the webstart JNLP file) so anytime these change, it causes a little bit of pain.

2. There are new jars required for the client (e.g. jboss-transaction-client.jar).

3. Had all manner of problems getting our oracle datasource to work. In 3.0.4 we were using an oracle-service.xml file to do this, I got multiple wierd errors trying to use this same deployment file in 3.2.1. I finally ended up having to go with an oracle-ds.xml file (which, I must admit is much simpler).

4. From what I could see, anything which was a compliance warning in JBoss 3.0.4 is pretty much guaranteed to be an error in 3.2.1. Granted - we should've fixed the warnings a long time back... These are silly things like a method on an EJB interface forgetting the RemoteException in its throws clause, etc.

5. It looks like they implemented cusom tag pooling starting with JBoss/Jetty 3.2.1... It was always my understanding that the servlet container would call release() on each TagHandler instance for custom tags before it re-used them, but I guess that was a slight misunderstanding of the spec. The actual behavior exhibited here is that the container will eventually call release() on the custom tag, but not between usages. I had to rearrange some of the "reset to default values" logic in a few custom tags to get around this (not too hard to fix once I figured out what was going on).

6. The move broke our WebStart client for IE users... Our webstart JNLP file is generated from a JSP file (pretty common). The mime type is set very early on for this file to be of type "application/x-java-jnlp-file", but for some reason, when we switched to JBoss 3.2.1, anytime an IE user clicked on our webstart link, it would popup the download dialog and ask the user where they wanted to save the local file. After a bit of consternation, I was able to get around the problem by defining a servlet mapping which makes IE thinks its really hitting a JNLP file for the webstart link (when in reality its still hitting the JSP).

   <!-- HACK: This entry is only present to make IE treat the resulting
          HTTP response as a JNLP file instead of a JSP file. -->
      <servlet>
         <servlet-name>FakeJNLP-IE-Workaround</servlet-name>
         <description>our dynamically generated JNLP file (generated by this JSP)</description>
         <jsp-file>/FsxWebStart.jsp</jsp-file>
      </servlet>
      <servlet-mapping>
         <servlet-name>FakeJNLP-IE-Workaround</servlet-name>
         <url-pattern>/FsxWebStart.jnlp</url-pattern>
      </servlet-mapping>