Hi Ralf,
Ralf Joachim wrote:
> Hi Werner,
>
> Werner Guttmann schrieb:
>> Hi Ralf,
>>
>> Ralf Joachim wrote:
>>
>>> Hi Werner,
>>>
>>> TMR.Loader holds TMF and properties to allow lazy initialization of TM.
>>> Another posibility to implement this would be to maintain TMF,
>>> properties and initialized TM in different maps in TMR. It may also be
>>> possible that another class (e.g. DatabaseRegistry, DatabaseContext)
>>> could handle the lazy initialization.
>>>
>>> The only reason why someone would need that (lazy init of TM) could be
>>> that he loads multiple jdo-conf ...
>>>
>> So in that case, the JDO configurations would carry a name attribute,
>> right, to distinguish them from each other ?
>>
> Yes.
>>
>>> with different TM but uses only one in
>>> his application. With the lazy initialization of the TM's he prevents
>>> failures from the other TM that could not be instantiated or looked up.
>>>
>> Assuming that this would be on the same classloader (e.g. the class
>> loader from a web application), would this really make sense ? I always
>> thought that our users would like to be informed about any
>> misconfigurations as soon as possible, i.e. at startup time, similar to
>> mapping problems.
>>
> I remember a request for lazy initialization of database instances. Not
> sure if this also requested lazy initialization of TM but I think we
> have introduced it in this context.
>
> About 2 weeks ago I have had a peek in this area of code myself when
> looking at an open issue to refactor DatabaseRegistry. Targets of this
> refactoring should be to make code easier to understand and make Castor
> bootstrapping compliant to JPA. An first outcome of this was the
> refactoring of ConnectionFactories. To get JPA compliant we will also
> need to support persistence.xml files as an alternative to jdo-conf. If
> you compare this 2 configurations you will recognize that
> persistence.xml allows to specify a transaction manager for each
> database instance. My impression is that this will also make
> bootstrapping code much simpler and may also influence the lazy
> initialization of TM.
>
> Do you have any problems with TM handling or what caused you to look at
> this area of code again? I you don't mind to share.
I am currently working on introducing two new classes, named
JDOManagerfactoryByFile and JDOMansgerFactory. Both classes will
basically allow you to configure the required properties to instantiate
*one* (and one only) JDOManager instance.
As you can see by looking at the file names above, this will allow
configuration though a standard JDO configuration file (ByFile), or
though a set of setter methods (setMapping, setTransactionDemarcation,
setDatabaseEngine, setDataSource....) (using java 5.0 enums etc.)
Why all this ? When working on the Mavenization of the CPACTF test suite
(its POM, introducing sql-maven-plugins executions, ...), I - once again
- came to realize that I want to be able to configure Castor JDO without
having to use a JDO configuration file. And I think that the JdoConf
classes we introduced years ago don't really fit this need any more.
I think the code will most likely look similar to
BasicDataSource dataSource = new BasicDataSource();
dataSource.setUsername(...);
...
Mapping mapping = ....
...
JDOManagerFactory factory = new JDOManagerFactory();
factory.setDataSource(dataSource);
factory.setTransactionDemarcation(TransactionDemarcation.Local);
factory.setMapping(mapping)
factory.setDatabaseEngine(DatabaseEngine.MYSQL);
factory.setXXX(...);
factory.setDatabaseName("test");
JDOManager manager = factory.createInstance("test");
This will have a couple of advantages:
a) You can supply external javx.sql.DataSources.
b) Configuration is easy, and can be supplied more easily from outside
(without having to make available a JDO configuration file for each test
suite invocation, ...)
c) It's a step towards where frameworks like Hibernate and various JPA
providers are.
d) It will allow me to remove a lot of work-arounds in the Spring ORM
code for Castor JDO.
e) I am sure there's more .. ;-)
Cheers
Werner
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
