Another option that I meant to mention is
having the jsps that are hit initially (probably only one in our case), do a
check for JDK 1.4 (assuming there’s a decent, inexpensive way to do this –
check a system property?) If the appserver is not running 1.4, then send a
meaningful message to the client that the app requires 1.4 (contact your
administrator, whatever)
This doesn’t address finding out
before the first client hits the appserver. But anyone deploying the war will
at least connect to the app once, at which time they will see a nice clear
message in their browser, not buried in some appserver log file, or scrolled
off the window where some appservers display stdout.
What do you think about the two
approaches? How about both? You could do the jsp message for the user and also
have a servlet init check the jdk version (via system property?) and print a
message if it fails, with or without throwing ServletException (if your jsp can
run without the servlet in place).
From: Herbers, Joe
[mailto:herbers@xxxxxxx]
Sent: Wednesday, September 01,
2004 3:48 PM
To: users@xxxxxxxxxx
Subject: [cinjug-users] WebApps:
how not to deploy?
Let’s say you have a web application that requires
Java 1.4. Is there a good way to prevent it from deploying on an
appserver if the appserver is only running 1.3?
What I’ve noticed by default on at least one appserver
is that you won’t see an issue till a client hits a JSP page that
references a class file, at which point the client gets a message like
“The major.minor version '48.0' is too recent for this tool to
understand.”
This isn’t very clear! Rather than this
appearing to the first user who hits the server, we’re thinking perhaps
it would be better to print an error message on startup. However, since
the output may be buried in a log file somewhere (for example on Oracle
9i’s AppServer) it seems like the only way to get attention is to prevent
deployment of the war as well. What do you think?