Craig
Thanks very much, nothing like a complete answer to a question!
Take care, Rich
"Craig R. McClanahan" wrote:
> On Mon, 18 Mar 2002, Rich Baldwin wrote:
>
> > Date: Mon, 18 Mar 2002 11:51:45 -0500
> > From: Rich Baldwin <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > Subject: Adding a system property?
> >
> > I have a system property which I have added to my build.properties file
> > and my build.xml
> > file. Ant builds and deploys w/o any errors. However, my tomcat
> > servlet cannot "find" this
> > new system property. What is the trick here? There is nothing in my
> > build.xml file to tell
> > tomcat explicitly about this property, but how would I do that? Where
> > can system properties be
> > set in tomcat?
> >
>
> The "build.properties" file is only consulted when you *build* Tomcat, not
> when you *run* it.
>
> > To recap
> > In build.properties
> > metadata.xmlfile=project.xml
> >
> > In build.xml
> > <property name="metadata.path"
> > value="${catalina.home}/webapps/${app.name}/${metadata.xmlfile}"/>
> >
>
> To get system properties defined at Tomcat runtime, you will need to set
> an environment variable -- either CATALINA_OPTS (Tomcat 4.x) or
> TOMCAT_OPTS (Tomcat 3.3.x). For example:
>
> CATALINA_OPTS=-Dmetadata.xmlfile=/path/to/the/file.xml
> $CATALINA_HOME/bin/startup.sh
>
> However, system properties are not the best way to provide configuration
> information to servlets, because they are global to the entire container
> and hard to manipulate. You should look at using <context-param> or
> servlet initialization parameters inside the web.xml file to provide this
> sort of configuration data.
>
> If you want to do this kind of thing without modifying the web.xml file
> (which would typically be the case if you're deploying the same webapp in
> lots of different environments), here is an apporach that works in Tomcat
> 4 because it requires the JNDI namespace that Tomcat 4 provides:
>
> * In your web.xml file, declare an <env-entry> element
> for the configuration property, optionally with a default value:
>
> <env-entry>
> <env-entry-name>metadata.path</env-entry-name>
> <env-entry-value>/default/path/to/metadata.xml</env-entry-value>
> <env-entry-type>java.lang.String</env-entry-type>
> </env-entry>
>
> * In your server.xml file, add a <Context> element that defines
> the actual value for *this* installation of the webapp:
>
> <Context path="/mypath" ...>
> <Environment name="metadata.path" type="java.lang.String"
> value="/the/real/path/to/metadata.xml"/>
> </Context>
>
> * In your application, you grab the value you need like this:
>
> IniitalContext ic = new InitialContext();
> String metadataPath = (String) ic.lookup("java:comp/env/metadata.path");
>
> (This is the javax.naming.InitialContext class from JNDI. The servlet
> spec defines that all environment entries are in the "java:comp/env"
> namespace.)
>
> * This will pick up the default value (if nothing was set in server.xml)
> or the override value (if you did set it).
>
> The nice thing about this is that it doesn't mess up any other webapp that
> might be using the same property name -- environment entries are
> per-webapp instead of being global. It also requires zero changes to your
> webapp itself (or its web.xml file) to customize behavior differently on
> different installations.
>
> > Thanks, Rich
> >
>
> Craig
>
> --
> To unsubscribe: <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
