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
