incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Connelly <dsconne...@adelphia.net>
Subject Re: ManageableCollectionUtil should not throw "unsupported" JcrMapping exception.
Date Mon, 04 Sep 2006 13:43:47 GMT
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 <the.mindstorm.mailinglist@gmail.com> wrote:
>
>> On 9/4/06, Dan Connelly <dsconnelly@adelphia.net> 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
>> > >
>> > >
>> > >
>> >
>> >
>>
>
>


Mime
View raw message