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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957756#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...