Re: [castor-dev] Request a command-line parameter to specify superclass

Brent Hale Tue, 02 Sep 2003 09:42:58 -0700

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


--
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

Re: [castor-dev] Request a command-line parameter to specify superclass

Reply via email to