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
