I just completed converting a major web application from Websphere 2.x with
JSP 0.91 to Resin 1.1 with JSP 1.1. It wasn't easy but it also wasn't
tremendously difficult.
The biggest problem wasn't really JSP 1.x at all but the changes from
servlet 2.1 and 2.2. With Websphere we were using servlet 2.0 and in order
to get things like server side includes we used non-standardized methods in
javax.servlet.http.*. These methods are significantly different on 2.0 vs.
2.1 and some are completely removed or deprecated to not work at all.
We also have a fairly strange JSP implementation. We don't use java beans
at
all. We have a variety of different servlets that we extend from the JSPs.
This is supported in both JSP 0.91 and JSP 1.x but oddly not supported in
JSP 0.92. We were also using the "method" page directive which isn't
supported in JSP 1.x.
The mechanical changes from JSP 0.91 to JSP 1.x are fairly trivial. If you
have a huge number of JSPs to convert (we had several hundred) it would
make
sense to figure out a way to do translations using a search and replace
tool. I just wrote a quick and dirty script in Perl that takes regular
expressions for search and replace. Any page directives must be changed to
match the new syntax in JSP 1.x. For us this was <%@ page import="... %>
and
<%@ page extends="... %> statements. I also had to remove the <%@
method="..
%> statements since they no longer exist--more about this later. Websphere
also added default imports that are different from Resin's. I don't know if
this is now a standard but I had to add several page import statements to
each JSP.
In addition to the page directives, we were using the variable "session" in
our application. It was used in just about every JSP file. I had to
globally
change the name from "session" to "sess".
The removal of the <%@ method=".. %> directive caused a change in the logic
of the program that I'm not fully sure of the consequences yet. The method
directive allowed the JSP developer to use any method name as the service()
method. The removal of this means that our initializations that were
occuring only once per JSP compilation are now occuring on every invocation
of the servlet. This may impact performance in ways that I'm not currenly
able to see. If it does, I will have to find a way to use the _jspInit()
method to replace the initialization that we were doing.
So far all of these changes are almost 100% mechanical. They don't impact
the program structure in any real way. There are changes caused by servlet
2.1 and 2.2 that are far more problematic. The main problem is in the area
of includes. With Websphere 2.x and JSP 0.91 the include mechanism we used
was to use the method javax.servlet.http.HttpServletResponse.callPage()
found in the websphere implementation but essentially undocumented. The
latest servlet spec(s) have a new class called RequestDispatcher that
performs the same function but it takes different arguments. One of these
arguments is the servlet context. This is easily available from the servlet
or the JSP but it isn't derivable from any other source as far as I can
tell. This meant that I had to find every instance of where we were using
callPage() and make sure that the servlet context was available by passing
it in as a parameter. Luckily this was made easier by the fact that we
already had wrapped the undocumented callPage functions in preparation for
it being changed.
After passing in the servlet context (the implicit object named
"application" in JSP 1.x) we were able to use RequestDispatcher.include()
to
perform the equivalent function after executing the flush() method on the
output stream (the implicit object named "out" in JSP 1.x). This flushing
has consequences. After a flush, your application isn't allowed to write
any
new headers. For our purposes this only impacted the
javax.servlet.http.HttpServletResponse.sendRedirect() method which works by
setting a header error code which causes a temporary redirect to a new
page.
It can't be called reliably after calling our include function.
The other problem was with getting the path info from the servlet request.
We never really solved the problem in the equivalent way that we had solved
it under JSP 0.91. The problem is that the path returned from
javax.servlet.http.HttpServletRequest.getPathInfo() always seems to be null
under servlet 2.1. I never got around to solving this problem but simply
changed the code to not require this functionality any more.
There were dozens of other less systematic problems with Servlet 2.1 too
but
those were relatively easy to overcome as well.
I hope this helps. I would say that the effort is absolutely necessary if
you intend to keep using JSP. The world is leaving Java 1.1.x and JSP 0.9x
behind very quickly. It was absolutely essential for us.
-----Original Message-----
From: Sreedhar Vaddi [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 15, 2000 5:18 PM
To: [EMAIL PROTECTED]
Subject: JSP 0.91 to JSP 1.0/1.1
Anyone have info on converting from JSP 0.91 to
JSP 1.0/1.1?
how to's? examples? or any kind of info is valuable.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
