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
