You could still use the application startup listener if it?s just a war file
and throw a ServletException if the JVM version isn?t 1.4 or above. Try
this...
Try
{
Class.forName( ?java.util.regex.Matcher? ); // Came out in 1.4!
}
catch( ClassNotFoundException e )
{
throw new ServletException( "This web application requires version 1.4+
JVM." );
}
-----Original Message-----
From: Robert Casto [mailto:robert@xxxxxxxxxxxxx]
Sent: Wednesday, September 01, 2004 4:13 PM
To: users@xxxxxxxxxx
Subject: RE: [cinjug-users] WebApps: how not to deploy?
-->
Wouldn?t you want to avoid the ClassNotFoundException as well? It is not
severity of the problem but the fact that the problem exists at all. I too
have run into this and I think Joe Herbers has a good point. There needs to
be some way of knowing before hand that the deployment is going to be able
to run before using a browser to test it.
I guess all you can do is see what is installed on the server. I would be
curious to know what you guys come up with as it would help me greatly with
upgrades at various customer sites, especially if the sites are running
older version of software.
Robert Casto
Phone: 513-755-2221
robert@xxxxxxxxxxxxx
From: James Carman [mailto:james@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 01, 2004 4:06 PM
To: users@xxxxxxxxxx
Subject: RE: [cinjug-users] WebApps: how not to deploy?
However, if that servlet class was compiled using the JDK 1.4 compiler, it
would throw an error, because the JVM wouldn?t know how to load the class.
You need to tell your compiler to compile your classes so that they are
compatible with the 1.3 releases. They can still depend upon the
1.4-specific classes, but the class file format would be compatible with the
older JVMs. That way, the worst thing that could happen would probably be a
ClassNotFoundException unless you?re using assertions.
-----Original Message-----
From: Mascolino, Mark R. [mailto:mark.mascolino@xxxxxx]
Sent: Wednesday, September 01, 2004 3:59 PM
To: users@xxxxxxxxxx
Subject: RE: [cinjug-users] WebApps: how not to deploy?
I don't believe that there is any cross-app server way of having an app veto
its deployment. The best you could do is a load-on-startup servlet that
checked things out and threw a ServletException in the case that everything
wasn't ok. Not perfect, but at least you should get a failure message right
away.
Mark Mascolino
Hewlett Packard
Managed Services - GTS
eBusiness Services - P&G Cincinnati
+1 513.983.4714
mark.mascolino@xxxxxx
The information transmitted is intended solely for the individual or entity
to which it is addressed and may contain Hewlett Packard Company
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of or taking action in reliance upon this
information by persons or entities other than the intended recipient is
prohibited. If you have received this email in error please contact the
sender and delete the material from any computer.
-----Original Message-----
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?
|