Hi John, Hi Lukas,
I can only repeat what Lukas has already said. If there's problems that
are reproducible, please create a new Jira issue and attach a (JUnit)
test case that enables us to replay the problem.
Cheers
Werner
On 30.01.2010 14:14, Lukas Lang wrote:
Hello John,
I have very limited knowledge in this area, but I'll at least try to give you
some answers.
Based on your information given, I'm not able to reproduce your problem. I've
just verified correct behavior of Castor XML 1.3.1 regarding loading of a
properties file from the classpath.
As far as I know, there has nothing changed in the way, Castor looks up
properties files. I just did a quick search through the issues of the last two
years and could not find any evidence that the documentation diverges from the
implementation.
From an engineering point of view, I would not recommend adapting Castor's
original properties file, but of course it is your decision. I would either set
necessary properties on the XMLContext, if I was you.
Regards,
Lukas
Am 30.01.2010 um 00:15 schrieb John Shott:
Castor Community:
I seem to be terribly confused about what our options are in terms of making
sure that we use a castor.properties file that is different from the default
castor.properties file that is shipped in the Castor XML jar file. We are in
the process of upgrading to Castor 1.3.1 and I believe that the rules for
finding and using the castor.properties file have changed.
Here is what I believe that the latest reference information says:
*** Begin copy of reference information***
By definition, a default configuration file is included with the Castor XML
JAR. Custom properties can be supplied using one of the following methods.
Please note that the custom properties specified will override the default
configuration.
* Place a file named castor.properties anywhere on the classpath of your
application.
* Place a file named castor.properties in the working directory of your
application.
* Use the system property org.castor.user.properties.location to specify the
location of your custom properties.
Please note that Castor XML - upon startup - will try the methods given above
in exactly the sequence as stated above; if it managed to find a custom
property file using any of the given methods, it will cancel its search.
*** End copy of reference information***
Thus far, the only thing that I have been able to make work is copying the
non-default castor.properties file that we wish to use into the directory from
where either our client or our servers are started. For us, at least, this
isn't terribly convenient.
Here are my questions:
1. It appears as if having the castor.properties file in one of our
application jars (that is on an explicitly set classpath) does not work. I
think that this is what we always did in pre-1.3 versions of castor. Is this
true in castor 1.3.1?
2. I've tried to start our application with "java
-Dorg.castor.user.properties.location=/usr/local/etc/our_castor.properties ...." and
that doesn't seem to work either. Am I doing something wrong? Note: somewhere else I
read that rather than setting the property org.castor.user.properties.location I should
define the property org.castor.properties.custom on the java command line and I tried
that, but I can't seem to make it work either.
3. If we are content to have a single, non-default version of castor.properties
on our machines, can we simply unjar castor-1.3.1-xml.jar, modify
org/exolab/castor/castor.properties, and re-jar castor-1.3.1-xml.jar?
I'd appreciate anyone's clarification of exactly how castor 1.3.1 finds a
non-default castor.properties file because I seem to have gotten myself
hopelessly confused on this score.
Thanks,
John
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
