Re: Can a java program know what kind of server it is running on?
Mike Kaufman wrote:
ServletContext.getServerInfo() returns the name and version of the
servlet container on which it is running - see the Servlet API javadoc
for details.
You still have to parse the string for names over which you have no control.
This may seem like not such a big deal - after all, you know which containers
you're using, right? You just probe them and record what strings they use,
right? It couldn't be that volatile, right?
In practice, I've seen reliance on a vendor-defined string reach back and bite
the team. I worked once for a large oranization that used a big-name Java
application server. We, too, relied on strings returned from the vendor
library to interact with the environment in a certain way. During the
six-month development cycle, the large organization upgraded the servers and
the strings' content changed, not only the information but the format of it.
The core API team had to go back and re-engineer the library for the change.
It wasn't even a major version-number upgrade.
While getServerInfo() locks down the format, at least, we still have to hope
JEE vendors aren't all that likely to change the name part too quickly. I
know of no such industry promise, nor of any standard to lock down what the
product calls itself. It just leaves me at risk to rely on such
uncontrollable data.
For example, suppose for your need there is no meaningful difference between
the various flavors of Sun Application Server and the various flavors of
Glassfish, or correspondingly, between Apache Geronimo and IBM WebSphere.
But you discover that BEA's server underwent a change and you have to map
different versions differently.
With getServerInfo() you have an arbitrary mapping between server versions and
desired configurations that has to be hard-coded. With a context variable you
have a direct representation of the mapped value, i.e., the configuration
itself - no mapping required, and therefore no hard-coding of the mapping,
just of the desired configurations. It's also expandable more easily if you
discover you need a new configuration - you merely create a new subclass of
your Configurator class and instantiate it reflectively based on the context
parameter.
--
Lew