We have an application that is comprised of a client side component run on phones, and a server side component which communicates with the phones and links them to our other SOA architectures. This was previously running on WebLogic 7, but since we are shifting to JBoss, it was decided to move this application over.

For the most part, the port went smoothly. Removal of WebLogic specific classes was a simple task, getting it to compile under the new environment took a little time and tinkering but it, too, went smoothly. After getting the ported application deployed to the server and letting some of the phones communicate, strange things started to happen. After some time trying to debug the situation, we found the problem. Without getting into too much nitty-gritty about how the application (phone or server) works, the responses coming from the server differ in one small way that breaks functionality on the phone. Mainly, we are setting the content type to a specific type (?application/eventstream?). When this response leaves the server, it has become ?application/eventstream;charset=ISO-8895-1?. While there is nothing wrong with this from an HTTP standpoint, then phone application is exclusively looking for ?application/eventstream? and nothing else.

Now, probably the simplest thing to do to fix the issue would be to change a ?.equals? to a ?.startsWith? or a ?.indexOf(?)>=0? inside the phone code. However, there are some 3000+ phones in the field and the procedure for getting the application on the phones and actually updated is a long and arduous one. The change would have to be server-side, at least as a temporarily until we reach a point where an update can be made to the phone application. So, back to work looking for where this string is modified in the JBoss (or to be more exact, Tomcat) codebase.

It can be tracked to the class org.apache.coyote.Response. Inside the getContentType() method, there is a small section of code that is checking for encoding, and appending it on the string before it?s returned. It?s an easy task to comment out that small section and recompile the class. However, it?s not so easy to figure out what to do with the class. The solution that seemed to work was to take the class, jar it up, and throw that jar into the JBoss instance?s \lib directory. When the class-loader started loading, this was picked up first and was therefore the instance of the class used from there on. Problems do exist with this, however. The override is instance wide, which means that any other applications deployed to that instance also have the changed class. It also makes for a headache going forward, as this class needs to be checked with every new version to make sure that it is still compatible with the other code around it.

I tried looking for ways to make it local to the application and found a few possibilities with the class-loader, but none seemed to override the original class. I also tried to think of different implementation strategies, such as implementing a custom servlet (it?s currently a set of JSP pages), but these seemed to also use the same underlying class.