You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rich Baldwin <Ri...@noaa.gov> on 2002/03/18 19:51:32 UTC

Re: Adding a system property?

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 <Ri...@noaa.gov>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: Tomcat Users List <to...@jakarta.apache.org>
> > 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:   <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>