Discussion:
Confused about castor.properties search in Castor 1.3.1 ...
John Shott
2010-01-29 23:15:05 UTC
Permalink
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
Lukas Lang
2010-01-30 13:14:45 UTC
Permalink
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
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.
*** 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.
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
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Werner Guttmann
2010-02-03 20:12:01 UTC
Permalink
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
Post by Lukas Lang
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
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.
*** 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.
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
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
John Shott
2010-02-04 02:13:21 UTC
Permalink
Lukas and Werner:

Thanks for your comments and I appreciate knowing that you both find
that things work for you in the way that the documentation changes. I'd
be happy if I could pick up my slightly modified castor.properties file
from the classpath because that way I have control over that for
everyone running our Castor-based application.

Let me ask you a follow-up question:

First, castor-1.3.1-xml.jar contains the default castor.properties file
(well, org/exolab/castor/castor.properties, correct)?

If I also include a slightly modified
org/exolab/castor/castor.properties file in part_of_my_application.jar,
then does the "version" of the castor.properties file that I get depend
on the order that part_of_my_application.jar and castor-1.3.1-xml.jar
are listed in the class path?
In my case, I think that I have part_of_my_application.jar listed before
castor-1.3.1-xml.jar. Does that mean that I'm reading the modified
castor.properties file from part_of_my_application.jar .... but then
immediately overwriting it, in effect, when it reads the default
castor.properties file from castor-1.3.1-xml.jar?

Or, if several jar files in the class path contain
org/exolab/castor/castor.properties files .... say the default and one
or two others ...
then does it use the first one that it finds and ignores any that are
included in jar files appear later in the classpath?

Thanks,

John



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Werner Guttmann
2010-02-04 19:17:59 UTC
Permalink
Hi John,
Post by John Shott
Thanks for your comments and I appreciate knowing that you both find
that things work for you in the way that the documentation changes. I'd
be happy if I could pick up my slightly modified castor.properties file
from the classpath because that way I have control over that for
everyone running our Castor-based application.
First, castor-1.3.1-xml.jar contains the default castor.properties file
(well, org/exolab/castor/castor.properties, correct)?
Yes.
Post by John Shott
If I also include a slightly modified
org/exolab/castor/castor.properties file ...
And that's where things start turning wrong. You must not use the
package prefix 'org/exolab/castor', as a custom property file needs to
be relative to root. In other words, simply add castor.properties to
your class path somehow (in a standard Maven build, include the file at
src/main/resources), and it will be picked up.

I hope this resolves your problem.

I still like to know, though, why you are using a different location,
and as such deviate from the documentation on this subject. Is it that
the documentation is not clear enough ? If so, where exactly ?

Cheers
Werner
Post by John Shott
in part_of_my_application.jar,
then does the "version" of the castor.properties file that I get depend
on the order that part_of_my_application.jar and castor-1.3.1-xml.jar
are listed in the class path?
In my case, I think that I have part_of_my_application.jar listed before
castor-1.3.1-xml.jar. Does that mean that I'm reading the modified
castor.properties file from part_of_my_application.jar .... but then
immediately overwriting it, in effect, when it reads the default
castor.properties file from castor-1.3.1-xml.jar?
Or, if several jar files in the class path contain
org/exolab/castor/castor.properties files .... say the default and one
or two others ...
then does it use the first one that it finds and ignores any that are
included in jar files appear later in the classpath?
Thanks,
John
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
John Shott
2010-02-04 19:37:45 UTC
Permalink
Werner:

Thanks for your help .... you are correct, I believe that I had been
incorrectly adding our castor.properties in our jar file as
org/exolab/castor/castor.properties instead of as simply
castor.properties at the root level. Looking at it again, I can't
really fault your documentation .... it says that the castor.properties
will be loaded in the following order:

Castor loads the castor.properties in the following order:
* From classpath (usually from the jar file)
* From {java.home}/lib (if present)
* From the local working directory

My mistake was in trying to make things more complex than they needed to
be .... by introducing an entire /org/exolab/castor hierarchy in my jar
file in which to locate a custom castor.proerties file rather than
simply adding as castor.properties. I would have been better off had I
simply read the documentation and not poked around to find that the
default file that castor uses is in /org/exolab/castor/castor.properties
file in castor-1.3.1-xml.jar.

So, I believe that this resolves my confusion .... thanks for your
patience and clarification.

John


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
Werner Guttmann
2010-02-04 20:36:31 UTC
Permalink
Hi John,

don't worry about this mis-reading. Still, if you thin that the docs
could be improved, feel free to attach a short patch to a Jira issue
that makes things less ambiguous.

Cheers
Werner
Post by John Shott
Thanks for your help .... you are correct, I believe that I had been
incorrectly adding our castor.properties in our jar file as
org/exolab/castor/castor.properties instead of as simply
castor.properties at the root level. Looking at it again, I can't really
fault your documentation .... it says that the castor.properties will be
* From classpath (usually from the jar file)
* From {java.home}/lib (if present)
* From the local working directory
My mistake was in trying to make things more complex than they needed to
be .... by introducing an entire /org/exolab/castor hierarchy in my jar
file in which to locate a custom castor.proerties file rather than
simply adding as castor.properties. I would have been better off had I
simply read the documentation and not poked around to find that the
default file that castor uses is in /org/exolab/castor/castor.properties
file in castor-1.3.1-xml.jar.
So, I believe that this resolves my confusion .... thanks for your
patience and clarification.
John
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Loading...