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

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

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
>
>
>

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
>>
>>
>>
>
>