On Thu, 18 Jul 2002, Will Hartung wrote:
>
> This all came out of the fact that it seems essentially impossible to create
> a webapp according to the 2.3 spec that uses file based storage and have it
> be usable "out of the box" with zero basic configuration to start up. For
> example, I don't think that there is a (portable) way for a servlet to
> change its own "parameters". Say the webapp comes with some "reasonable
> default" for File pathnames, but a user wishes to change them. They cannot
> do that using the servlet itself (through some HTML Form/GUI mechanism), in
> a portable way.
>
The approach I would use for this is to pass the default pathname as an
<env-entry> in the web.xml file, and access it via JNDI calls in the
servlet. Containers that support JNDI resources for webapps (which means
Tomcat 4 plus every J2EE server in the world) provide mechanisms for the
administrator to change the value of environment entries, either in a
configuration file (like server.xml for Tomcat) or as part of the process
of deploying the application, with zero changes to the WAR itself.
The mechanism to do the configuration customizaton is not "portable" in
the sense of being identical on every server, but it is available.
> Even with a databased app, there's no way for a servlet to change its
> "default" JDBC URL and persist that change, it has to be done through the
> configuration files or in the webapp itself.
>
That's actually a good thing (changing it via configuration).
Consider an environment with three servers (development, test, and
production). Naturally, each is connected to a different database. The
last thing you want to do is have to change JDBC strings in your webapp
depending on which server you are deploying to.
Using a <resource-ref> to declare a reference to a connection pool that is
configured for you by the server administrator is much less tedious and
error prone -- and you don't have to do anything at all to your
application itself.
JNDI resources are your friend.
> That would be a nice bit to concentrate on in the future I think.
>
> Best Regards,
>
> Will Hartung
> ([EMAIL PROTECTED])
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
