Hi Nick,
I've added it to the xml-faq. --Keith Nick Stuart wrote: > > This is all great information to have. > Do you suppose you could add some of the missing parts into the website > under the configuration section. Mainly, the order in which it looks for > properties, being able to programmatically overwrite properties (I > realize a good read through the API will get this as well but still), > the fact that only supplied properties are overwritten. I think that's > about it as far as what we've discussed here. :) > > -Nick > > -------Original Message----- > --From: Keith Visco [mailto:[EMAIL PROTECTED] > --Sent: Tuesday, June 22, 2004 4:09 PM > --To: [EMAIL PROTECTED] > --Subject: Re: [castor-dev] Easier way to configure castor... > -- > -- > -- > --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-formatte > d-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 > -- > -- > > ------------------------------------------------------------------------ > ----------------------------------------------------------- > 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
