Jay is correct, Castor loads the castor.properties in the following
order:
1. From classpath (usually from the jar file)
2. From {java.home}/lib (if present)
3. From the local working directory
Each one overrides the previous. So you don't have to come up with a
properties file with all the properties and values, just the ones you
want to change.
You can also use LocalConfiguration#getProperties() to change the
properties values programatically.
--Keith
Jay Goldman wrote:
>
> Castor first loads the castor.properties file it finds by package name using
> the classpath (i.e., the one in the jar), it then looks for an additional
> castor.properties file in a few places (I don't remember the exact order but
> it looks for castor.properties (no package name) (a) using the classpath,
> (b) in the user's home directory, and maybe a 3rd place) and the values in
> this 2nd properties file (if found) override the values set in the first
> one.
>
> jay goldman
>
> -----Original Message-----
> From: Werner Guttmann [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 21, 2004 5:57 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Easier way to configure castor...
>
> Hi CLaude,
>
> just a couple of random remarks inline. Please bear in mind that I have not
> looked at the patch below, and will defer doing so until later.
>
> Werner
>
> PS Please no HTML email to this mailing list as per
> http://castor.exolab.org/lists.html#A-note-about-HTML-formatted-e-mail.
>
> --Original Message Text---
> From: Claude Vedovini
> Date: Fri, 18 Jun 2004 16:42:38 +0200
>
> Hi,
>
> We went through this problem and were not satisfied with "classpath"
> solution, first because it a bit more tricky for a on site consultant to
> change a
> classpath in Websphere ...
>
> werner --> Hmm, that is a difficult statement per se .. ;-). First off, I
> didn't mean to imply that the CLASSPATH should be changed for this to work.
> In
> general, it is a very bad idea to have to change the CLASSPATH of a
> Websphere instance at all ... Assuming that you are deploying a web
> application,
> by definition the web app should be self-contained, i.e. everything required
> to run the web app should be part of it. Having said that, this could and
> should include any castor.properties file to override the system defaults.
> By nature, such a file (when placved eg. in WEB-INF/classes of a web
> appllication will 'override' the castor.properties file stored in
> castor-0.9.5.3.jar stored in WEB-INF/lib of your web app.
>
> . than a system property and because the property file override all the
> properties defined in this of the jar file.
> werner --> Afaik, you do not have to specify all properties in this file,
> just the ones you actually want to override.
>
> We wanted something our consultants were already familiar with and the
> possibility to override existing properties, but only those we actually want
> to
> change.
>
> Consultant were familiar with log4j so we decided to add some lines of code
> to Castor to consider a "castor.configuration" system property and if it
> exist
> use the defined url to override the defaults.
>
> Here is the patch (it is not against the current code base but I'd be
> surprise it changed a lot since then):
>
> Index: org/exolab/castor/util/Configuration.java
> ===================================================================
> RCS file:
> /cvs/castor/castor/src/main/org/exolab/castor/util/Configuration.java,v
> retrieving revision 1.3
> diff -u -r1.3 Configuration.java
> --- org/exolab/castor/util/Configuration.java 26 Sep 2003 05:36:07 -0000
> 1.3
> +++ org/exolab/castor/util/Configuration.java 17 Dec 2003 14:57:56 -0000
> @@ -97,6 +97,16 @@
> public abstract class Configuration
> {
>
> + /**
> + * String specifying the name of the system property defining
> + * an URL for the castor.properties file
> + * <pre>
> + * castor.configuration
> + * </pre>
> + */
> + public static final String castorPropertiesURL =
> "castor.configuration";
> +
> +
> /**
> * Names of properties used in the configuration file.
> */
> Index: org/exolab/castor/util/LocalConfiguration.java
> ===================================================================
> RCS file:
> /cvs/castor/castor/src/main/org/exolab/castor/util/LocalConfiguration.java,v
>
> retrieving revision 1.6
> diff -u -r1.6 LocalConfiguration.java
> --- org/exolab/castor/util/LocalConfiguration.java 26 Sep 2003 05:36:07
> -0000 1.6
> +++ org/exolab/castor/util/LocalConfiguration.java 17 Dec 2003 14:57:51
> -0000
> @@ -699,6 +699,33 @@
> //-- do nothing
> }
> }
> +
> + // -------------------------------
> + // Get the overriding configuration from the system property
>
> + // ignore if not found. If found, merge any existing
> + // properties.
> + try {
> + // get the system property
> + String configurationStringURL =
> + System.getProperty(castorPropertiesURL);
> + // If we do have the url, we try to load it
> + if (configurationStringURL != null) {
> + URL confURL = new
> URL(configurationStringURL);
> + // open stream from URL
> + InputStream uis = confURL.openStream();
> + if (uis != null) {
> + _props = new Properties(_props);
> + // load new properties
> + _props.load(uis);
> + uis.close();
> + // we do not set up the found var
> + }
> + }
> + } catch (Exception except) {
> + //Ignore
> + }
>
>
>
>
> Cheers,
> Claude
>
> > -----Original Message-----
> > From: Nick Stuart [mailto:[EMAIL PROTECTED]
> > Sent: 17 June 2004 16:30
> > To: [EMAIL PROTECTED]
> > Subject: Re: [castor-dev] Easier way to configure castor..
> >
> >
> > Ya, that's what I figured the case would be. And for the most
> > part this
> > isn't a big deal as you say, stick it in the lib folder for
> > web-apps and
> > you're good to go. Thanks for the reply!
> >
> > -Nick
> >
> > -------Original Message-----
> > --From: Leo Joncas [mailto:[EMAIL PROTECTED]
> > --Sent: Thursday, June 17, 2004 9:14 AM
> > --To: [EMAIL PROTECTED]
> > --Subject: Re: [castor-dev] Easier way to configure castor...
> > --
> > --We use an external castor.properties file and never mess
> > with the jar.
> > --
> > --The only catch is that the directory containing the
> > --properties file needs to be known to the classloader.
> > --
> > --In the case of using Castor with our JBoss-based web app,
> > --that just means putting the castor.properties file in the
> > --same location as the castor.jar file for loading by JBoss,
> > --i.e. in the directory JBOSS_HOME\server\yourservername\lib.
> > --
> > --For a stand-alone Java app, that just means that your
> > --CLASSPATH should include both the castor.jar file path AND
> > --the path of the directory containing the castor.properties
> > file, i.e.
> > --
> > --
> > CLASSPATH=%CLASSPATH%;yourcastorpath\castor-xml.jar;yourcastorpath
> > --
> > --
> > --Leo Joncas
> > --
> > --
> > -------Original Message-----
> > --From: Nick Stuart [mailto:[EMAIL PROTECTED]
> > --Sent: Thursday, June 17, 2004 8:37 AM
> > --To: [EMAIL PROTECTED]
> > --Subject: [castor-dev] Easier way to configure castor...
> > --
> > --
> > --I was just wondering if there would be an easier way to setup
> > --Castor so that people could configure it from outside the
> > --jar. I find that it can be a little annoying (all though not
> > --all that difficult) to open up the jar file, edit the
> > --properties file, and then repackage it or update it.
> > --
> > --If there is a way to do this just yell at me. :) But my idea
> > --was to possibly setup up an external properties file that
> > --would get read in first. And any properties in it would
> > --override what ever is in the internal one. (Kind of like how
> > --Ant does it currently). Currently I'm not sure how castor
> > --reads the property file and uses it, i.e.. Does it read it in
> > --all at once, or only when it needs to find out a setting when
> > --running. Guess I'll have to take a look at this, if it's the
> > --first case I would imagine this change wouldn't be all that
> > --difficult, if it's the second I'm not sure what would be involved.
> > --
> > ---Nick
> > --
> > --
> > --
> >
> >
> __________________________________________________________________________
> . This email and any files transmitted with it are CONFIDENTIAL and intended
> solely for the use of the individual or entity to which they are addressed.
>
> . Any unauthorized copying, disclosure, or distribution of the material
> within
> this email is strictly forbidden.
> . Any views or opinions presented within this e-mail are solely those of the
> author and do not necessarily represent those of Odyssey Asset Management
> Systems SA unless otherwise specifically stated.
> . An electronic message is not binding on its sender. Any message referring
> to
> a binding engagement must be confirmed in writing and duly signed.
> . If you have received this email in error, please notify the sender
> immediately
> and delete the original.
>
> ------------------------------------------------------------------------
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
