Hello all-
I am currently re-working our development environment to bring us up to
date with the latest and greatest features of
jakarta-turbine-(2|torque|maven). One of the big problems that I am
having is deciding how to handle the following situation:
There are a few key classes in the gray area between Torque and Turbine.
Most notably, DBConnection, Criteria, and StringKey (these are the ones I
have run into so far) that exist in both modules. The existing Turbine
API's use the Turbine versions of the crossover classes.
My question is, what should I do with my code that uses these classes?
The options that I see before me are as follows:
1) Continue as I was, using the coupled version of Torque to generate OR
mapping classes with all of the Turbine versions of the crossover classes.
2) Generate OR mappings using stand-alone torque and change the templates
to point to the Turbine versions of the crossover classes.
3) Generate OR mappings using stand-alone torque with no changes to the
templates and change the Turbine code to use the Torque versions of the
crossover classes.
4) Use Torque versions wherever I can, and use the Turbine versions
wherever I am forced to in order to comply with the Turbine APIs. This
means that I have a connection pool in Turbine and one in Torque, which
works but seems nasty.
The main problem that I am having right is with the
ValueParser.setProperties() API, which as you know uses reflection to
figure out what properties to set based on the values in the value parser.
I get an exception becuase I pass in a stand-alone Torque generated OR
class whose id attribute is of type org.apache.torque.om.StringKey, while
the BaseValueParser only knows how to manage
org.apache.turbine.om.StringKey. Again, the options are pretty clear but
I am interested in hearing if others have run into this and what is the
best strategy for working around it in the interim. Also, I am interested
in hearing how the developers will be handling this going forward - will
the value parser classes be dependent on Torque? Will there always be a
turbine version of these crossover classes? Or will the value parsing
functionality be factored out of the Turbine classes and put in a common
package so that Turbine is not dependent on Torque?
-B
--
Brian Lawler
--
To unsubscribe, e-mail: <mailto:turbine-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:turbine-user-help@jakarta.apache.org>
|