incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <>
Subject Re: JCR Mapping enhancement request(s)
Date Mon, 02 Jan 2006 09:47:39 GMT
Hi Alex,

Happy new year ! It is nice to see you here :-)

Well, I have no special comments to your suggestions. Your proposed
patches will be welcome. Can you add them in the Graffito jira
application ?  Concerning your third suggestion : yes there is a plan
to add a cache service in this mapping framework.

Do you plan to use this mapping tools in Magnolia ?

Kind regards,

On 1/2/06, Alexandru Popescu <> wrote:
> Hi!
> This is my first mail to this list and I would like to wish everybody here a Happy New
> I have started to try using Graffito JCR Mapping into the project I am working now. I've
> investigating the code so far and I would like to ask you about the possibility of adding
a few
> enhancements.
> 1/ new attribute in the mapping DTD.
> I would like to have an additional fieldType=fully_qualified_class_name in field-descriptor
and also
> bean-descriptor. This would bring 2 benefits:
> i/ the possibility to generate a source class from the mapping
> ii/ the possibility to remove an inspection step (f.e. in ObjectConverterImpl).
> If you agree with this I can provide the needed patch quite immediately :-).
> 2/ AtomicTypeConverters
> The atomic type converters are dependent on a ValueFactory which can be retrieved from
the current
> Session. I would like to ask if it is possible to add a setValueFactory(ValueFactory)
to the
> AtomicTypeConvert interface and make all the default implementors have both a no-arg
constructor and
> the current one.
> This will allow an easy creation of converters (((AtomicTypeConverter)
> converterClass.newInstance()).setValueFactory() instead of the longer version using the
> constructor).
> Once again if you agree with this change I can provide the needed patch quite immediately.
> 3/ Reflective access
> Another thing that I am looking for (but not so urgent) would be to optimize the reflective
> by caching some of the information (so that the beanutils are not used every time). Currently
> reflection performance is quite good, and I don't expect to see a big impact on this,
> considering large sets of objects the impact may be important.
> cheers,
> ./alex
> --
> .w( the_mindstorm )p.
> =======================================================
> Me      :            Alexandru Popescu
> Contact :     the_mindstorm[at]evolva[dot]ro
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Projects:
>    TestNG   [co-author]:
>    Magnolia [committer]:
>    WebWork  [committer]:
> =======================================================

View raw message