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
