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
