Joe,
I am in favor of doing both. A nice clear
message when you try to deploy the application is probably the easiest to see. Keeping
the servlet out of memory is a nice benefit. You really won’t know until
you try and running the application is trying it. Only at that time can you
tell what environment you are in. Checking System.getProperties() is an option
but it might be hidden from you by the server. It is worth a try though but
each container is going to have its own take on whether to make it visible or
not.
From: Herbers, Joe
[mailto:herbers@xxxxxxx]
Sent: Wednesday, September 01,
2004 4:32 PM
To: users@xxxxxxxxxx
Subject: RE: [cinjug-users]
WebApps: how not to deploy?
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?