Hi Thomas, Thanks again for your time. I hope you can still help me a bit further.
I can try to get EMF to put my own combined EMF/OJB collection class in that location. However ojb is still responsible for the instantiation of the collection and expects a zero-argument constructor which is not offered by EMF.
Also afterwards going through the emf code by hand to change the list class or manually add zero-constructor list classes for specific members is not the approach I am looking for because I try to implement a generic layer which requires no hand coding for this model specific part. Also the query customizer helps to get the right content of the list but does not influence the list object used (as far as I could see).
I looked at the use of the ManageableCollection and its interface (and use) does not seem to complex (it has two add methods and one getIterator). The documentation lists also an afterStore method but I could not find that in the source code. The removal aware collections broker.util.collections need a bit more attention but are also doable for user-specific collections.
However for the user defined CollectionClass ojb assumes a zero-argument constructor. So, just trying again, but does a collection factory not make sense (returning either a ManageableCollection or a removal aware variant)? With a collection factory the user has much more control/flexibility when creating Collection objects.
Ojb supports the concept of ObjectFactories and to me the instantiation approach of a user specific object or a user specific collection is not that different.
The collection factory could be defined in the CollectionDescriptor just as the user defined CollectionClass. The user-defined CollectionClass (implementing the ManagableCollection) is only used in a few places in ojb (CollectionPrefetcher, MtoNCollectionPrefetcher and QueryReferenceBroker). So to replace this with a user-defined factory approach, only isolated changes are required. Or did I miss something here?
Again thanks for your time!
gr. Martin
Thomas Dudziak wrote:
Adding my own Collection impl. (inheriting from EMF and implementing the required ojb interface) is not possible because the type of the collection is not known until runtime and the EMF collection classes do not have empty constructors (see below).
But if I look at the code snippet you provided, I see that the used
collection type is EObjectContainmentEList and its usage is fixed
(i.e. specified in the class and instantiated via new). Now if you can
configure the class that EMF puts there, then you can use your own
OJB-adapted implementations, e.g. OjbEObjectContainmentEList ?
I try to build a generic integration between emf and ojb so that classes generated by emf are persistable using ojb with no additional hand coding. EMF does not generate a set method for collection members. The collection can be retrieved using the get method and adapted directly. This I think is a clean approach of EMF.
As mentioned I made a small change (5-6 lines) to the retrieveCollection method of ojb QueryReferenceBroker to get this working for me but I do not want to keep my own copy of this class. Is there a possibility to send this as a patch or let this be reviewed (just trying :-).
Sure, just send it to the dev list. But please make sure that the unit tests pass as before.
However, I nicer approach than I implemented would work with collection factories or so.
Are there any ideas to make the QueryReferenceBroker/collection creation more pluggable which I can work with? I am also willing to try things out or code myself if this would help out here.
Mhmm, the main problem is that OJB sets its own collection types in order to maintain information about which sub-objects need to be persisted and so on. You should have a look at the usage of ManageableCollection to see what OJB does with collections. Also you might want to have a look at the query customizer functionality; for both you'll find some documentation in this and the next paragraph here:
http://db.apache.org/ojb/docu/guides/advanced-technique.html#manageable-collection
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
With Regards, Martin Taal
Springsite Barchman Wuytierslaan 72b 3818 LK Amersfoort tel: +31 (0)33 462 02 07 fax: +31 (0)33 463 77 12 Mobile: +31 (0)6 288 48 943 email: [EMAIL PROTECTED] web: www.springsite.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
