Dan, I'm sorry but I don't understand what you are doing. If you need to support another kind of collection (or Map), there are 2 alternatives : 1/ Build your own ManageableCollection and reference this class in the mapping file. 2/ or promote this class into the ManageableCollectionUtil (if this is a generic/well know collection or map).
Please, let me know why it is not possible to create a simple ManageableCollection ? In therory, you should know modify the code managing the collections inside the framework. Thanks, Christophe On 9/4/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
On 9/4/06, Dan Connelly <[EMAIL PROTECTED]> wrote: > What I ended up doing for this problem, to avoid the exception, was to > make a local modification in ManageableCollectionUtil. It still > throws the exception (if needed) but my specialized list collection > class is now easily coerced to a ManageableCollection with my > replacement code. > > This is a hack, but a much smaller hack than trying to specialize either > the objectConverter or the collectionConverter to do the wrapping. > > I would like to see the CollectionConverter interface extended with a > method: > private ManageableCollectionFactory getManageableCollectionFactory() > such that the ManageableCollectionFactory class would be used in much > the same way that ManageableCollectionUtil is ued. > > The ManageableCollectionFactory would continue to throw the > "unsupported" JcrMapping exception (if needed), but presumably would > wrap all of the application's collection classes correctly. > > I haven't liked the fact that the framework is using this factory like class to handle collections, but haven't got the time and energy nor the time to refactor it. A good refactoring patch would be pretty welcome. ./alex -- .w( the_mindstorm )p. > > Dan Connelly wrote: > > > I want to use a custom collectionConverter, MyCollectionConverterImpl. > > > > That collectionConverter can decide what to do with "unsupported" > > collections from my *given* object model. (Object model cannot be > > changed.) In particular, MyCollectionConverterImpl will wrap an > > unsupported collection as a ManageableCollection and delegate its work > > to a standard collection converter. > > The collection type is discovered by reflection in the > > objectConverter, so it cannot be coerced in the ocm mapping. > > > > Unfortunately, the default objectConverter invokes its own wrapping > > tool, ManageableCollectionUtil, just before the call to > > insertCollection in the custom collectionConverter. > > ManageableCollectionUtil will throw an exception before the custom > > collectionConverter gets its chance to wrap the unsupported collection > > type. The call to insertCollection in the custom > > collectionConverter is never invoked. > > > > A workaround would be to over-ride method insertCollectionFields using > > a custom objectConverter. However, this method is private in the > > standard objectConverter. Thus the method work cannot be delegated. > > Code would need to be copied into the custom objectConverter. Not > > good. But even if this method was public and code copying was not > > needed, the object converter is not the right place for collection > > conversions. > > > > Why not make the collectionConverters responsible for throwing an > > exception on (truly) unsupported collection types? > > Don't throw this exception from ManageableCollectionUtil. Just leave > > an "unsupported" collection type alone there and let the > > collectionConverter deal with any unsupported collection type that may > > be given to it. > > > > -- Dan > > > > > > > >
-- Best regards, Christophe
