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

[Dan Connelly]

Christophe

Okay, there is a solution along these lines, now that I think about 
it.   Thanks for forcing a re-think.

My requirement is that all my model code must be generated by Eclipse 
EMF.    I have to work with the code as produced by the standard tooling 
there, without alterations.    The usual generative process gives 
collections the EList interface.    EList is not "well-known".

However, there is also a standard tooling for an EMF coercion into SDO 
(Service Data Objects).     SDO is well-known (in certain circles, at 
least).    Even better, the SDO coercion uses the standard List 
interface for its collections.     So this should work with your 
ManageableCollectionUtil as is (but I haven't tried yet).

For SDO, see Apache Incubator project Tuscany.    
http://incubator.apache.org/projects/tuscany.html

See also JSR-235.   http://www.jcp.org/en/jsr/detail?id=235

An SDO DataObject is quite similar to a JCR Node.    The SDO->JCR 
mapping is well worth pursuing.   It imposes only a slight restriction 
on my generative process..

I will give it a try and report back.    I will start a new thread for 
the SDO outcome (or problems).

      -- Dan



Christophe Lombart wrote:

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