I've been developing on 2 different app servers lately. I started out developing on BEA Weblogic 7 because it was the chosen app server for the project I'm on. I love Weblogic, it's robust, powerful, easy to use. However, for development, it's slow to start up and even in development mode, it doesn't always pick up every change when you are working in exploded format.
An acquaintance recommended that I try Resin. It's a small, fast XML app server. It also has a JSP/servlet engine. I really like this server. When I said before that it was fast, I should have said it was FAST! In addition to the performance, it picks up any change made to an exploded format directory. Also, you can reconfigure the server and its database connections on the fly. VERY NICE for development.
Now, here's the rub. Both the Resin server and the BEA Weblogic server support the latest servlet spec (2.3) from Sun. However, there are some subtle differences in implementation. Small example - I'm using the Jakarta HTML taglibs. We developed a JSP while solely using Weblogic that have option groups that start with <html:option value=""></html:option>. This was done to put a blank choice in the options box. Under weblogic, this renders with no problems. However, Resin throws a null pointer exception when executing the doAfterBody method. I found that if I change the line to add a non-breaking space, then the page compiles and executes properly - <html:option value=""> </html:option>.
This is an example of something I've seen time and again among servers implementing the J2EE standards. There is enough room in the standard for interpretation during implementation. I think this is probably to be expected of any OPEN standard. If you have a proprietary system, then of course you have total compliance to all the nuances of the standard. However, this doesn't prevent the problem from being frustrating.
I've seen articles in magazines and around the web say that you should develop to the J2EE reference implementation from Sun and then you can be guarenteed that the application will deploy anywhere. I submit that this is not true. I believe that there are enough differences between each implementation to reveal a host of small bugs such as the one I mention.
So, what's the solution? I don't know. I think we live with it. We're far better off than we used to be in terms of code portability. I think open standards are a wonderful thing that prevent lock in. I'm willing to live with these frustrations. I'm willing to be mostly compatible compared to platform-locked, aren't you?
9:23:01 AM 
|
