Re: Setting properties outside of the WAR

[Ritchie Young <ri...@mirametric.com>]

Thanks for the response but that wasn't quite what I was getting at.

The idea was that there should be some easy way for an administrator to set
a property for the application. It just strikes me that the TOMCAT_OPTIONS
variable is a slightly cumbersome way especially when there start to be a
few more applications.

I thought that the "Context" tag in server.xml wouldn't be a bad place to
incorporate application specific settings such as where the application can
find it's properties file. This would also allow for multiple instance of
the same application to use different configurations but only one WAR file.

Cheers
Ritchie

> To set properties dynamically in your application you can try this command
>
> java.lang.System.setProperty(key,value)
>
> Or
>
> System.getProperties().put("HTTPClient.dontChunkRequests", "true");

Re: Setting properties outside of the WAR

[Ritchie Young <ri...@mirametric.com>]

Craig R. McClanahan wrote:

> The settings in server.xml are designed to configure Tomcat's own
features --
> not your application. Your app is responsible for that.  You can do things
in a
> portable way (for example, call
> ServletContext.getResource("/WEB-INF/myprops.properties")), or not, as you
> choose.

The problem with that is that you are getting the properties from within the
WAR. It's just the same as setting init parameters inside web.xml. This is
my point. There should be a portable way of accessing parameters set by the
administrator who probably shouldn't be opening up a WAR file and playing
around with it's contents.


> Keep in mind that the intent of web applications is that they are *stand
alone*
> gadgets, to be dragged and dropped onto a servlet container (*any*
container,
> not just Tomcat) and work correctly.  Given that, it does not make sense
for the
> servlet API to provide any mechanism to access resources outside of the
WAR.

If the intention is that they be drag & dropped, the administrator still
needs some way of configuring the particular instance. By limiting the
portable configuration options to what's inside the WAR, you are at least
requiring a separate copy of the WAR for each running instance of the same
web app within the container.

What's worse is that dropping a new version of the WAR would wipe out any
configuration changes made to the original.

Why can't the servlet API define calls to access parameters defined outside
of the WAR but tell the container writers that they can implement the
setting and storage of these parameters however they see fit?

> You are free, of course, to implement any such technique (such as passing
the
> absolute pathname to a properties file in a servlet initialization
parameter),
> but you are making it harder on people who want to deploy your webapp in a
> variety of environments, as well as limiting the set of environments in
which
> your app can run (for example, an ISP might prohibit file access in order
to
> protect the various web apps from each other).

Absolutely. That's why I don't want to do it.

Thanks for responding to my query. I hope my reply doesn't seem negative.
WARs are really cool but I still think that something is missing here.

Cheers
Ritchie

Re: Setting properties outside of the WAR

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Ritchie Young wrote:

> Thanks for the response but that wasn't quite what I was getting at.
>
> The idea was that there should be some easy way for an administrator to set
> a property for the application. It just strikes me that the TOMCAT_OPTIONS
> variable is a slightly cumbersome way especially when there start to be a
> few more applications.
>
> I thought that the "Context" tag in server.xml wouldn't be a bad place to
> incorporate application specific settings such as where the application can
> find it's properties file. This would also allow for multiple instance of
> the same application to use different configurations but only one WAR file.
>

The settings in server.xml are designed to configure Tomcat's own features --
not your application.  Your app is responsible for that.  You can do things in a
portable way (for example, call
ServletContext.getResource("/WEB-INF/myprops.properties")), or not, as you
choose.

Keep in mind that the intent of web applications is that they are *stand alone*
gadgets, to be dragged and dropped onto a servlet container (*any* container,
not just Tomcat) and work correctly.  Given that, it does not make sense for the
servlet API to provide any mechanism to access resources outside of the WAR.
You are free, of course, to implement any such technique (such as passing the
absolute pathname to a properties file in a servlet initialization parameter),
but you are making it harder on people who want to deploy your webapp in a
variety of environments, as well as limiting the set of environments in which
your app can run (for example, an ISP might prohibit file access in order to
protect the various web apps from each other).

>
> Cheers
> Ritchie
>

Craig McClanahan