Keith, Just a reminder to provide a link for jdomapper (http://o2xmapper.sourceforge.net/jdomapper) from the castor site. I am currently working on a user guide and adding ddl generation capabilities to make this a truly top down tool. Thanks Shelly
-----Original Message----- From: Keith Visco [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 4:22 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Configuration for Source Generator/castorbuilder Hi Brian, I assume you are trying to create source code and compile "on-the-fly" or "dynamically"? The typical use of the source generator, either manually or in a build-script, shouldn't cause problems because the source generator wouldn't be used from an application server. Here is what currently happens (or what we intend to happen) with the CVS version: 1. load properties from JAR (defaults) 2. load properties from {JAVA_HOME}\lib (globally overridden defaults) 3. load properties from local config file, if it exists. With each step, properties with the same name are overwritten. Now with the SourceGenerator it's all static, so using muliple source generators in the same JVM that require different configurations could cause problems. I've made some recent changes in the CVS to the general castor configuration which uses "castor.properties" to help with the "static" issue. It still needs some work, but should behave better than previous version of Castor with respect to using multiple Castor applications within the same JVM. The initial configuration code was written back in 1999, and has suffered from it's bad design (blame Assaf and myself for that) ever since. I'm slowly trying to make it more friendly. If you would like to help out on this issue please add yourself to the cc list on bugs 897 and 1070 and we can keep the thread going there for tracking purposes. Thanks, --Keith Brian Goetz wrote: > > I think the configuration process used by source generator is > considerably more error-prone than it needs to be. The docs state > that some properties can be set through system properties, whereas > other must be set through castorbuilder.properties. Further, the > requirement to put customized castorbuilder.properties ahead of the > JAR in the classpath is quite error prone. > > In other open-source projects I've worked on, we've employed a > search-path approach to configuration which is quite easy to implement > and less confusing for the users. Here's what I would propose: > > Use the o/e/c/b/castorbuilder.properties file in the JAR as DEFAULTS. > Don't recommend that users modify this file. > > Encourage users to put customizations in a castorbuilder.properties > file loaded from the classpath, but not at o/e/c/b. This lets the > user-specific file override the system-wide defaults that live in the > JAR. > > Allow system properties to be used for all castorbuilder properties. > This is safe as castor properties are fully qualified with the o.e.c > package name. > > So the search order for configuration properties would be: > - system property > - application properties file > - JAR properties file (defaults) > > This is easy to implement and doesn't force the user into classpath > contortions, which are especially difficult in J2EE environments where > multiple apps may share the JAR and you don't have explicit control > over classpath ordering. > > I would be happy to contribute code for this if you would like it. > (For all I know, it may even work this way already to some degree, but > the docs have just not been updated.) > > Also, the particular property o.e.c.b.nspackages is particular > problematic, as it requires you to specify all the packages in one > definition. This makes it harder to build modular systems where > different modules contribute different optional schema elements. It > would be nice if there were a way to configure this also in a package-per-property manner as well, like > o.e.c.b.nspackage.URL=package > > Again, I'm willing to contribute on this if it will help. > > -- > Brian Goetz > Quiotix Corporation > [EMAIL PROTECTED] Tel: 650-843-1300 Fax: 650-324-8032 > > http://www.quiotix.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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
