db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject Opinions on solving a map initialization problem?
Date Wed, 10 May 2006 17:06:11 GMT
Hey All,

I'm almost done with the changes to the database mapping structure
I proposed a week or so ago.  (Thomas - I wasn't REALLY bothered by
rewriting the stuff... just a poor attempt at humor... 8)  )

I'd like to run the solution to a problem I found while testing this 
in the Maven test-project by this larger audience for any potential 
"gotchas" I might have missed.

First, the basic issue is that the Torque Generated code will be located

in a user defined package.  So, if Torque's core code needs to access
any generated classes, it needs to have a pre-defined way to access 
such information.  

I was going to solve this using properties files and searching the 
class path for them.. However, the Maven & Ant Torque processes don't 
copy Java support files from the source to target directories.  E.g. 
*.properties, *.xml, etc., located in the src/java directories don't get

copied to the target/classes directories. (But FWIW Eclipse's build 
process does).

So how do we ensure that this linkage problem doesn't occur due
to build processes not dealing with not Java files?

I am planning to replace the properties file with a Generator built
class file who's name is based on the XML Database name that 
will live in a specific package rather than the user chosen package.
(FYI, the DB Name will be normalized to a Java acceptable name).
These will just be "stub" classes that extend the full MapInit classes
in the user defined map directory.

For example, if there are Torque schema's named books and default,
the Generator code will create a the following entries in the 
torque.java.dir (e.g src/java):


The initialize process will simply recreate the specific init class
from the db name and dynamically call the full map initialization

This should make for a "build process safe" implimentations. Since:

- Each DB will have a unique Init class name.
- They are Java source files that all build compile processes should 
  handle correctly.
- JVMs allows for packages to be split over multiple directories 
  and/or jars on the Classpath (to support patch jars, etc).  So the 
  "books" classes can be in a separate jar from the "default" classes.

Anyone see any problems with this?

Should I use another package name than org.apache.torque.linkage?
Maybe just torque.linkage?

Alternative methods I can think of but don't like for various reasons

Modify the Torque build to include properties, etc.  (But what if
the users building with some other tool?)

Add yet another property to Torque's configuration files that
specifies the initialize package location. (This would have to be the 
same in the generate and runtime configurations.)

Use the torque.compile.build.dir directory to find where the
compiled classes are being stored and generate the properties 
files there. (But IMHO, this property is not used frequently or set 
properly in the build setup and there may be some velocity 
issues around figuring out the actual file system location if 
references are relative.)

Greg Monroe    <Monroe@DukeCE.com>    (919)680-5050
C&IS Solutions Team Lead
Duke Corporate Education, Inc.
333 Liggett St.
Durham, NC 27701

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are confidential communication
or may otherwise be privileged or confidential and are intended solely for the individual
or entity to whom they are addressed.  If you are not the intended recipient you may not rely
on the contents of this email or any attachments, and we ask that you  please not read, copy
or retransmit this communication, but reply to the sender and destroy the email, its contents,
and all copies thereof immediately.  Any unauthorized dissemination, distribution or copying
of this communication is strictly prohibited.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message