RE: System properties
I agree that global properties are not ideal, it would be much better to be able to localise them for each web-application, I thought I would start by not asking for too much! From the replies that I have seen so far I will give the element a go. Basically setting a parameter for a particular web app which I agree means your web apps are less likely to have name clashes with parameters they set, as is the case with System properties, hence more encapsulated. Stu -Original Message- From: Jim Rudnicki [mailto:[EMAIL PROTECTED]] Sent: 20 November 2000 03:11 To: [EMAIL PROTECTED] Subject: Re: System properties > 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: > > > myproperty > 42 > > > Anyone think this is a good idea, or am I talking rubbish? It's a bad idea. Keep your web-apps encapsulated. There is two ways to think about a "global" service: - providing a service to many servlets, seems like a good thing or - bleeding out dependencies upon those that don't need them and allowing access to those that shouldn't be using it. bad things > PS. static, bad? It is useful! ... she said and meant _static initializers_ = bad, not static methods, and members. I concur. Jim
RE: System properties
John Thanks for that, will look into further and let you know. Stuart -Original Message- From: John Ellis [mailto:[EMAIL PROTECTED]] Sent: 17 November 2000 17:44 To: [EMAIL PROTECTED] Subject: Re: System properties According to the dtd: http://java.sun.com/j2ee/dtds/web-app_2.2.dtd There is an "env-entry" tag that has name-value pairs like you mentioned. The version of tomcat that I am using (3.1) did not seem to being doing anything with this entry. It does seem like it would be the perfect place for exactly what you are talking about. Does anyone know what this entry is (the dtd description did not specifically say how to get these values back -- I am assuming System.getProperties())? Does anyone know if more current version of tomcat support it? Will future versions? John Stuart Farnan wrote: > 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: > > > myproperty > 42 > > > 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
RE: System properties
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: myproperty 42 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
RE: System properties
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. 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=anotherprop ertyvalue:.."? Thanks for your help, Stuart -Original Message- From: Rachel Greenham [mailto:[EMAIL PROTECTED]] Sent: 17 November 2000 15:21 To: [EMAIL PROTECTED] Subject: Re: System properties On Friday 17 November 2000 14:27, you wrote: > Hi, > > I was wondering if it is possible to pass properties to Tomcat. I have > some classes which read various system properties in their static > initializers, and this works fine when using these classes on the command > line using "java -Dproperty=value". However I am not sure how to pass > these properties into tomcat when I start it. Is there something in one of > the XML files? yes, you can do it, by supplying it in TOMCAT_OPTS when invoking Tomcat. However, it's ugly and results in non-portable web applications (you need to set the properties on whatever servlet container is being used, and restart it, and some may not allow you to set such things). It would be *better* to put the properties you want into some config file specific to your web application, in WEB-INF, to be loaded through ServletContext.getResource(), or as servlet init parameters. Static initialisers? Ugh. Specify instead that your servlets are to be initialised and get the data then. Self-containment is the watchword for web applications. -- Rachel
System properties
Hi, I was wondering if it is possible to pass properties to Tomcat. I have some classes which read various system properties in their static initializers, and this works fine when using these classes on the command line using "java -Dproperty=value". However I am not sure how to pass these properties into tomcat when I start it. Is there something in one of the XML files? Thanks, Stuart ______ Stuart Farnan [EMAIL PROTECTED] NeoWorks Ltd+44 (0)20 7637 5429
