Sorry Brent, I led you down the wrong path. The "castor.properties" file is handled by the LocalConfiguration, but the "castorbuilder.properties" file is handled directly by the SourceGenerator class.
You're right, if "." is in your classpath, it will load the properties file from the working-directly, but if "." is not in the classpath, it's not picking them up. Usually "." is always in my classpath, so this is something I had not noticed before. We'll try to get that cleaned up. I've also reported the same information to your bug report: http://bugzilla.exolab.org/show_bug.cgi?id=1400 Thanks, --Keith Brent Hale wrote: > > I had not looked at LocalConfiguration, but have looked (and played) > with it now. > > Obviously I have not looked at it extensively, but by placing some debug > staements in the loadProperties() method of LocalConfiguration.java the > only file it tries to find is the castor.properties file -- not the > castorbuilder.properties file. > > Keith...you mentioned earlier in this thread to put a copy of > castorbuilder.properties into my "working directory (the directory in > which you will be executing your compile command)". Looking at the code > I wonder if you were assuming that "." was in everyone's CLASSPATH. > Unfortunately that was not the case for me. However, even after putting > "." in my classpath, the debug statements still inform me that > castorbuilder.properties is not being looked for by the loadProperties() > method of LocalConfiguration.java. > > Reading the javadocs for LocalConfiguration it states " * The > configuration file is loaded from the Java <tt>lib</tt> directory, the > classpath and the Castor JAR. ". It doesn't say anything about the > current working directory (granted I know how fast javadocs can get out > of sync so maybe I'm still missing something). The javadocs also only > refers to the castor.properties file. It says nothing about > castorbuilder.properties and, from my debugging, appears to never look > for it. > > The fix I proposed may not be the correct solution. Perhaps getting the > loadProperties() method of LocalConfiguration.java to be called for > castorbuilder.properties is closer to the correct solution. > > Please advise, > Brent > > Keith Visco wrote: > > >Hi Brent...did you also look at the code in LocalConfiguration? > > > >--Keith > > > >Brent Hale wrote: > > > > > >>OK...here's what I've found out. (When all else fails...look at the code ;) > >> > >>The loadProperties() routine in > >>org.exolab.castor.util.Configuration.java looks in Castor's jar file > >>first to find the properties files. It complains if it can't find one > >>there. > >> > >>Then it will look in "lib" directory below where java.home points to. > >>It gets the java.home value via this call: > >> javaHome = System.getProperty("java.home"); > >> > >>It does not complain if it can't find it here. As far as I can tell, > >>there is no code (in the 0.9.5 code base or the code at the Head) that > >>looks in the users working directory. > >> > >>And yes, if I stuck my properties file in java's lib directory it finds > >>it. But this is a poor solution. I want my team to be able to > >>regenerate these files on the fly and having to copy properties files > >>into Java's lib directory is not an acceptable way of handling this. > >> > >>If lines 885-909 in org.exolab.castor.util.Configuration.java were > >>changed to the following, then the configuration files will get pulled > >>from the current working directory. > >> > >> // Get overriding configuration from the current > >> // working directory, ignore if not found. If > >> // found merge existing properties. > >> String homeDir = null; > >> try { > >> homeDir = System.getProperty("user.dir"); > >> } > >> catch(Exception except) { > >> // Ignore probably running in an applet > >> } > >> > >> if (homeDir != null) { > >> > >> try { > >> file = new File( homeDir, fileName ); > >> if ( file.exists() ) { > >> properties = new Properties(properties); > >> properties.load( new FileInputStream( file ) ); > >> found = true; > >> } > >> } > >> catch ( IOException except ) { > >> // Do nothing > >> } > >> } > >> > >>If this is the behaviour it is suppose to exhibit can someone commit > >>this change? > >> > >>Thanks, > >>Brent > >> > >>Brent Hale wrote: > >> > >> > >> > >>>What am I doing wrong. At first I thought it must have something to > >>>do with maven. But then I created a batch file that I run to create > >>>the source files. In the same directory as the batch (which is also > >>>where I run it from) are my .properties files. But when I run it, my > >>>superclass property is still never being seen. > >>>Here's my output from a command prompt: > >>> > >>>C:\dev\projects\qbfccastor>java -cp > >>>../repository/castor/jars/castor-0.9.5.jar;. > >>>./repository/xerces/jars/xerces-J_1.4.0.jar > >>>org.exolab.castor.builder.SourceGene > >>>rator -i src/conf/qbxmlops21.xsd -package com.evnt.qbfccastor -types > >>>j2 -dest ta > >>>rget/castor/src > >>> > >>>target\castor\src\com\evnt\qbfccastor\InvoiceLineAdd.java already > >>>exists. overwr > >>>ite(y|n|a|?)a > >>> > >>> > >>>C:\dev\projects\qbfccastor>ls > >>>castor.properties genXML.xml maven.xml~ project.xml > >>>castorbuilder.properties maven.bak project.bak project.xml~ > >>>doit.bak maven.log project.properties src > >>>doit.bat maven.xml project.properties~ target > >>> > >>>C:\dev\projects\qbfccastor>grep superclass *.properties > >>>File castorbuilder.properties: > >>>org.exolab.castor.builder.superclass=com.evnt.qb.QBCastorBase > >>> > >>> > >>>But it doesn't seem to be getting picked up. I was using the > >>>castor.properties file to set the indent property. It did seem to get > >>>picked up properly. But not the castorbuilder.properties file. > >>> > >>>Any ideas? > >>>Brent > >>> > >>> > >>> > >>> > >>> > >>> > >>>Keith Visco wrote: > >>> > >>> > >>> > >>>>Hi Brent, > >>>> > >>>>You can place a *copy* of the castorbuilder.properties in your working > >>>>directory (the directory in which you will be executing your compile > >>>>command) and Castor will use that copy instead of the one in the jar. So > >>>>you don't need to unpack/repack the jar file. > >>>> > >>>>This is also true for the castor.properties file. Castor checks the > >>>>working directory before it checks the classpath. > >>>> > >>>>--Keith > >>>> > >>>> > >>>>Brent Hale wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>I'm new to Castor but have found that it will work nicely. Thanks, > >>>>> > >>>>>I'm using Castor to generate my classes from with Maven (which I would > >>>>>suggest to Castor since the current build - although easy - is rather > >>>>>unstandard..needing to use the batch file rather than Ant directly for > >>>>>instance). I need to be able to specify the superclass for my > >>>>>generated > >>>>>file. I've done this in the castorbuilder.properties file and then > >>>>>repackaged the jar. The build process packages the > >>>>>castorbuilder.properties file into it which I find less than useful. > >>>>>Ideally I want to download Castor standard jar file and be able to > >>>>>modify behavior external to it. Since the properties file is embedded > >>>>>into the standard jar file I don't know of a way to override it without > >>>>>re-jarring. If there is a way please tell me. > >>>>> > >>>>>I'm wondering if all of the options available via the > >>>>>castorbuilder.properties file could easily be made available via > >>>>>command > >>>>>line arguments. This would make it so an external process could use > >>>>>the > >>>>>standard jar file and modify its behaviour at will without having to > >>>>>rejar. > >>>>> > >>>>>Thanks > >>>>> > >>>>>-- > >>>>>Brent Hale > >>>>>Fishbowl Inventory > >>>>>www.fishbowlinventory.com > >>>>> > >>>>>----------------------------------------------------------- > >>>>>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 > >>>> > >>>> > >>>> > >>>> > >>-- > >>Brent Hale > >>Fishbowl Inventory > >>www.fishbowlinventory.com > >> > >>----------------------------------------------------------- > >>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 > > > > > > -- > Brent Hale > Fishbowl Inventory > www.fishbowlinventory.com > > ----------------------------------------------------------- > 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
