You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Alexandru Popescu <th...@gmail.com> on 2006/01/02 02:10:59 UTC
JCR Mapping enhancement request(s)
Hi!
This is my first mail to this list and I would like to wish everybody here a Happy New Year!
I have started to try using Graffito JCR Mapping into the project I am working now. I've been
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 actual
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 access,
by caching some of the information (so that the beanutils are not used every time). Currently the
reflection performance is quite good, and I don't expect to see a big impact on this, but
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]: http://testng.org
Magnolia [committer]: http://www.magnolia.info
WebWork [committer]: http://opensymphony.com/webwork
=======================================================
Re: JCR Mapping enhancement request(s)
Posted by Christophe Lombart <ch...@sword-technologies.com>.
Alexandru Popescu wrote:
>
> Hi Christophe and thanks for your quick answer.
>
> 1/ I will create 2 JIRAs for the mentioned points and let you know
> immediately.
>
> 2/ I am planning to use the mapping tools with my product that uses
> Magnolia. Later on, if the things proove to work well, Magnolia may
> become a good place to use it, cause it may bring a new dimension of
> features. Still, there are a few mapping scenarios that are not
> covered (even if currently I haven't reached them in my project, but I
> think some of them I will). My intention is to follow the Hibernate
> mapping strategies and see which ones can be applied successfully to
> JCR. As you probably know, at this moment Hibernate offers quite a
> good vision on mapping strategies.
>
> Please let me know what are your intentions regarding JCR-mapping
> module, so that we may be able to focus on the same track ;-).
You can follow our works from Jira.
In summary, nice works to do are :
* Add transaction support - I'm working on that. Almost finish
* Add caching features
* Add more mapping strategy : support inheritance, interfaces, add more
collection mapping strategy, ...
* Oliver is working on some tools like node type register and I think on
a jcr browser.
Regard,
Christophe
Re: JCR Mapping enhancement request(s)
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying on 1/2/2006 11:47 AM :#
> 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,
> Christophe
>
Hi Christophe and thanks for your quick answer.
1/ I will create 2 JIRAs for the mentioned points and let you know immediately.
2/ I am planning to use the mapping tools with my product that uses Magnolia. Later on, if the
things proove to work well, Magnolia may become a good place to use it, cause it may bring a new
dimension of features. Still, there are a few mapping scenarios that are not covered (even if
currently I haven't reached them in my project, but I think some of them I will). My intention is to
follow the Hibernate mapping strategies and see which ones can be applied successfully to JCR. As
you probably know, at this moment Hibernate offers quite a good vision on mapping strategies.
Please let me know what are your intentions regarding JCR-mapping module, so that we may be able to
focus on the same track ;-).
cheers,
./alex
--
.w( the_mindstorm )p.
> On 1/2/06, Alexandru Popescu <th...@gmail.com> wrote:
>> Hi!
>>
>> This is my first mail to this list and I would like to wish everybody here a Happy New Year!
>>
>> I have started to try using Graffito JCR Mapping into the project I am working now. I've been
>> 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 actual
>> 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 access,
>> by caching some of the information (so that the beanutils are not used every time). Currently the
>> reflection performance is quite good, and I don't expect to see a big impact on this, but
>> 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]: http://testng.org
>> Magnolia [committer]: http://www.magnolia.info
>> WebWork [committer]: http://opensymphony.com/webwork
>> =======================================================
>>
>
>
>
>
> !DSPAM:43b8f6e0670361126616474!
>
>
Re: JCR Mapping enhancement request(s)
Posted by Alexandru Popescu <th...@gmail.com>.
AtomicTypeConvertors JIRA issue: http://issues.apache.org/jira/browse/GRFT-83
Patch provided.
tia,
./alex
--
.w( the_mindstorm )p.
#: Christophe Lombart changed the world a bit at a time by saying on 1/2/2006 11:47 AM :#
> 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,
> Christophe
>
> On 1/2/06, Alexandru Popescu <th...@gmail.com> wrote:
>> Hi!
>>
>> This is my first mail to this list and I would like to wish everybody here a Happy New Year!
>>
>> I have started to try using Graffito JCR Mapping into the project I am working now. I've been
>> 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 actual
>> 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 access,
>> by caching some of the information (so that the beanutils are not used every time). Currently the
>> reflection performance is quite good, and I don't expect to see a big impact on this, but
>> 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]: http://testng.org
>> Magnolia [committer]: http://www.magnolia.info
>> WebWork [committer]: http://opensymphony.com/webwork
>> =======================================================
>>
>
>
>
>
> !DSPAM:43b8f6e0670361126616474!
>
>
Re: JCR Mapping enhancement request(s)
Posted by Alexandru Popescu <th...@gmail.com>.
#: Christophe Lombart changed the world a bit at a time by saying on 1/2/2006 11:47 AM :#
> 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,
> Christophe
>
First JIRA improvement request created for FieldDescriptor fieldType:
http://issues.apache.org/jira/browse/GRFT-82.
Patch provided.
Unfortunately for BeanDescriptor it cannot be done, cause it will need in fact 2 attributes:
fieldType and fieldTypeImpl. We can provide them when they are needed.
Waiting with interest your comments,
./alex
--
.w( the_mindstorm )p.
> On 1/2/06, Alexandru Popescu <th...@gmail.com> wrote:
>> Hi!
>>
>> This is my first mail to this list and I would like to wish everybody here a Happy New Year!
>>
>> I have started to try using Graffito JCR Mapping into the project I am working now. I've been
>> 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 actual
>> 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 access,
>> by caching some of the information (so that the beanutils are not used every time). Currently the
>> reflection performance is quite good, and I don't expect to see a big impact on this, but
>> 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]: http://testng.org
>> Magnolia [committer]: http://www.magnolia.info
>> WebWork [committer]: http://opensymphony.com/webwork
>> =======================================================
>>
>
>
>
>
> !DSPAM:43b8f6e0670361126616474!
>
>
Re: JCR Mapping enhancement request(s)
Posted by Christophe Lombart <ch...@gmail.com>.
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,
Christophe
On 1/2/06, Alexandru Popescu <th...@gmail.com> wrote:
> Hi!
>
> This is my first mail to this list and I would like to wish everybody here a Happy New Year!
>
> I have started to try using Graffito JCR Mapping into the project I am working now. I've been
> 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 actual
> 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 access,
> by caching some of the information (so that the beanutils are not used every time). Currently the
> reflection performance is quite good, and I don't expect to see a big impact on this, but
> 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]: http://testng.org
> Magnolia [committer]: http://www.magnolia.info
> WebWork [committer]: http://opensymphony.com/webwork
> =======================================================
>