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
