Ralf, I'll be having a look at points 3) and 4) ovwer the next few days. Basically, I think that introducing proper life-cycle behaviour to a stripped-down JDOManager class will be ... well, at least more straight-forward than now. We already have a close() method, and simply need to introduce proper checks in methods such as close() and getDatabase() to check whether the JDOManager instance is still active.
With regards to 4), I think that we should disregard 5) for the time being - until I finally find some time to start working no this seriously - and actually focus on what methods should be available on such a new JDOManagerFactory (and try to be inline with the JPA spec to some degree, so that we don't run into any suprises when we finally tackle it). I will be creating a new issue in a few minutes, and attach what I have as a base for a discussion. So far, I have moved all loadConfiguration() methods and createInstance(String) to the new class (and removed them from JDOManager, for simplicity, to be honest), and worked on the life-cycle methods. Bye Werner --------------- Werner, I thought about that myself a while ago when working in that area. At that time I defered that idea. 1. We first need to get rid of JDO as maintaining 3 interfaces to access Castor persistence makes things to complicated. 2. We first need to be able to execute tests with multiple configurations (jdo-conf and properties) and in J2EE environment. 3. The life cycle problem needs to be resolved first or at least by introducing the new interface. 4. The new interface as well as its configuration have to be in sync with JPA spec. 5. Different mapping syntax (JPA) need to be supported. 6. We also should care on other persistence mechanisms like LDAP when thinking about a change of that interface. And there are some more things to think about when changing the interface to Castor persistence once again. As outlined I would still defer that step until above issues are adressed. Having said that it seams to be the right way to go. Regards Ralf Werner Guttmann schrieb: > Ralf, > > I have been thinking about some issues to Castor JDO lately, and what > I'd really like to see implemented is a factory object for the > JDOManager. Right now, we have several (more or less complex) factory > methods on JDOManager itself. Personally, I'd like to move (or support > this in addition) to an additional JDOManagerFactory object to load JDO > configuration and ask for creation of JDOManager instances. > > A real benefit to me is that this would > > A) clearly separate responsibilities > B) create something similar to the XMLContext object on the XMl side > C) allow a much cleaner and lighter interface on the JDOManagerFactory > object, potentially moving towards setters only. In other words, if you > need an EntityResolver, set it; if not, not; etc. > > What's your view(s) ? > > Werner > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email -- Syscon Ingenieurbüro für Meß- und Datentechnik GmbH Ralf Joachim Raiffeisenstraße 11 72127 Kusterdingen Germany Tel. +49 7071 3690 52 Mobil: +49 173 9630135 Fax +49 7071 3690 98 Internet: www.syscon.eu E-Mail: [EMAIL PROTECTED] Sitz der Gesellschaft: D-72127 Kusterdingen Registereintrag: Amtsgericht Stuttgart, HRB 382295 Geschäftsleitung: Jens Joachim, Ralf Joachim --------------------------------------------------------------------- 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
