Ralf,
I am *not* working on anything related to JPA. I am only trying to add a
new factories/builders to Castor JDO so that instantiation of JDOmanager
instances is sufficiently eased.
And if you want me to continue with integrating e.g. support for JPA
annotations with Castor JDO (where a group of students has spent some
700 hours), you rather not ask me to wait for JPA API stuff .. ;-).
Regards
Werner
Ralf Joachim wrote:
> Hi Werner,
>
> this basically seams to go into the same direction that I have in mind.
> But your interface seam not to take care on JPA specification which is a
> prerequisit for changes at bootstrapping code of Castor in my opinion. I
> would really appreciate if you could take care on JPA bootstrapping and
> interfaces. At least I don't want to introduce something that
> contradicts to the requirements of JPA specification.
>
> As far as I understand JPA specification, configuration gets passed to
> PersistenceProvider with a PersistenceUnitInfo instance to create a
> EntityManagerFactory if you configure things programatically. When
> configuring with jdo-conf.xml or persistence.xml we could translate this
> into PersistenceUnitInfo also. EntityManagerFactory for JPA plays about
> the same role that JDOManager has for Castor.
>
> What I had in mind was to refactor current codebase to internaly use a
> class that implements PersistenceUnitInfo to hold configuration
> information first. If that is reached we could add support for
> persistence.xml and implement PersistenceProvider.
>
> The problem when starting at that area is that PersistenceProvider need
> to return JDOManager instances which does not yet implement
> EntityManagerFactory interface and therefore does not comply to JPA.
> Having said that I do not see a problem with this if we use that
> internally (e.g. for spring-orm) but we should not make this public
> until full compliance to JPA is reached.
>
> Regards
> Ralf
>
>
> Werner Guttmann schrieb:
>> 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
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
