[hibernate-dev] hiberate-commons-annotations and locating annotations

[Steve Ebersole]

After looking through this some more, I think what you say could almost 
work.  But:

1) Still need a way to determine the declarer of a property rather than 
just blindly accepting XProperty.getAnnotation(Convert.class).  This is 
needed for the Super/Sub MappedSuperclass/Entity case in my initial 
email to properly interpret Convert precedence.  Is the best option 
here a change to hibernate-commons-annotations, and if so what change 
specifically?  Adding `XClass XProperty#getDeclarer()`?

2) As you say, AbstractPropertyHolder does account for 
subclass/superclass precedence during its init.  But I am not sure how 
to hook in normalized path-based handling here.

2.a) It seems like there are times when 
org.hibernate.cfg.AbstractPropertyHolder#parent would be useful for 
what I need to do.  But there appears to be times when this is null.  
For entity mappings (ClassPropertyHolder) thats fine.  But for the 
others, that would be problematic.  Going back to the 
Person#homeAddress example, I'd really need the ComponentPropertyHolder 
for Person#homeAddress to register the converts with 
ClassPropertyHolder<Person> under the "homeAddress" base key 
("homeAddress.city" for example).  Is there a time here where 
AbstractPropertyHolder#parent would be null for 
ComponentPropertyHolder/CollectionPropertyHolder?
2.b) Is this AbstractPropertyHolder#parent the best way you see to 
handle path-based converts?  Or do you see a better option?



On Fri 30 Aug 2013 10:52:40 AM CDT, Emmanuel Bernard wrote:
> On Fri 2013-08-30 10:13, Steve Ebersole wrote:
>> Hit send too early...
>>
>>
>> On 08/30/2013 09:55 AM, Steve Ebersole wrote:
>>> Also, unless we have some normalization rules, my point was that
>>> we literally cannot do this today in annotations.
>>>
>>> Essentially the bug-a-boo is composites (and maybe collections as
>>> composite via allowance of "map.", etc).  We'd essentially have to
>>> normalize all paths for converters to be the composite form
>>> relative to the "root" composite parent.  In other words, given
>>> the "Person.homeAddress.country" example (home address being
>>> embedded of type Address), we'd have to normalize all path
>>> references for converters to be "homeAddress.country" and
>>> kept/managed on Person. The trouble is that this makes the order
>>> in which we process these levels very important, and I am just not
>>> sure I trust binders as they are to enforce that ordering.
>>
>> This ^^ is difficult to achieve in the "annotation reader".
>
> That's what is done for Attribute Override in AbstractPropertyHolder.
> You can control the order in which sub/spuer class a processed it and
> control how composition from a property holder to its parent is done.