I am looking at the HEAD version is this 1.1 (I am not that much of a cvs expert)?
No problem I will enter a feature request in jira and also attach some code (tested and all).
gr. Martin
Thomas Dudziak wrote:
On Apr 7, 2005 12:52 AM, Martin Taal <[EMAIL PROTECTED]> wrote:
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).
There is no way to configure which collection classes EMF uses ? Honestly, that would be stupid design on part of the EMF folks. But anyway ...
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.
Might be a leftover bit of documentation, the afterStore was present in the 1.0 branch.
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?
Mhmm, should be doable without that much effort then. Could you perhaps create a feature request in JIRA for this, stating some requirements that you would have for such a collection factory ? And if you happen to have some code that you could attach at the feature request :-)
Btw, we're talking about OJB 1.1 here, right ?
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]
