OK marvellous,
I get all that, TOMCAT_OPTS is not my first choice if it is just basically
the command line. On the subject of using a startup servlet to do the work
of reading the info and passing it on to the utility classes that need it,
this is an option, but would mean writing a servlet for to do this, and
also, anywhere else I use the utility classes, they would need to be
'initialised' in the same way by some other class in the other application.
This would of course have to happen before the class is used, and I had
thought that is should be possible to encapsulate all the details of the
connection pooling in one place, including the actions of reading the system
properties file. Yeah, all the stuff is in process, no separate database
access server.
>From the looks of things, it is just the way it is, although I was hoping
the there would be some way to put stuff in the web.xml file, maybe in the
servlet tag like:
<system-property>
<name>myproperty</name>
<value>42</value>
</system-property>
Anyone think this is a good idea, or am I talking rubbish?
Stu
PS. static, bad? It is useful! Singletons (you mentioned), cleanly handling
exceptions in constructors, general things you want to share between
instances, object caches, etc.
-----Original Message-----
From: Rachel Greenham [mailto:[EMAIL PROTECTED]]
Sent: 17 November 2000 16:18
To: [EMAIL PROTECTED]
Subject: Re: System properties
On Friday 17 November 2000 15:46, you wrote:
> Rachel,
>
> Thanks for that, about the static initializers... The classes that use
them
> are not servlets, merely utility classes are used in the web application
> and also elsewhere.
>
> For instance, a class, or series of classes that deal with database
> connection pooling, could conceiveably have a configuration file to let
> them know what pools to set up, min and max connections, where the server
> is, what the driver class is, etc. And these classes are useful in other
> apps, not only in web applications. Now of course you can hard code into
> the class, the file to load, but this is ugly, it is nicer to say "java
> -Ddb.properties=/home/stuart/db.properties". As the classes are not
> servlets, servletContext.getResource() is not really an option.
Yes it is. Your startup servlet reads these parameters, parses that data,
and
then invokes your utility classes with that initialisation data.
consider "static" harmful. :-) I only ever use it to define constants, like
database field names or whatnot, or to hold the instance of a
single-instance
class.
Basically, if your database accesses are going on in the same *process* as
your servlets, ie: you have some generic headless data-access javabeans that
do the work and you want to call them from your servlets, you should still
have a servlet that's initialised on startup of the web application, and
*that* initialises your data-access beans. That way you can also catch the
web application being shut down and cleanly close down your data-access
classes too.
If your data-access is happening in another process from your servlets, and
communicating over network sockets, eg: using RMI or XML/SOAP type thing,
then you initialise that task in any way you see fit - the servlet engine
just talks to it when it wants to. If you're doing this, you may well want
to
look seriously at EJB.
> I could not find anything about TOMCAT_OPTS on the web site, persumably
> this is an environment variable, what format do you put system properties
> in, is it like
>
TOMCAT_OPTS="db.properties=/home/stuart/db.properties:myproperty=anotherpro
>p ertyvalue:.."?
Not quite. TOMCAT_OPTS is just given to the java command line used to invoke
Tomcat, so it's in that format, ie: "-Ddb.properties=value" etc.
--
Rachel
