Re: DON'T IGNORE ManageableCollectionUtil should not throw "unsupported" JcrMapping exception.

[Dan Connelly <ds...@adelphia.net>]

Hmmm.   That didn't work either.   There really is no good way to do 
this except to copy code from ObjectConverterImpl into 
MyObjectConverterImpl where I can hack my ManageableCollection wrapper 
for collection types I need to support.    I also needed to make 2 
methods public in ObjectConverterImpl.   Ugh.    


Dan Connelly wrote:

> Oops.   This is problem is solved fairly easily by over-riding the 
> getCollection method.    (But, it is a bit tricky there to search the 
> type hierarchy of the Class collectionFieldClass to determine the 
> wrapper to use.)
>
> Sorry for posting half-baked my problems and solutions.   (But my 
> fumbling is a case-study on why the "Advanced Mapping Strategy" pages 
> need to be completed.)
>
>
> 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
>>
>>
>>
>
>