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]
