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

[Steve Ebersole]

The point is that, for converter, sometimes "the XML winning" isn't 
"the XML winning".  What I mean is that just like with @Convert, 
<convert/> can exist at the <entity/> or <basic/> level.

So given your example:

@Entity
public class Sub {
    ...
    @Convert( converter=Converter1.class )
    public String getIt() {
        ...
    }
}

and:

<entity class="Sub">
    <convert attributeName="it" disableConversion="true"/>
</entity>


The "XML winning", today, means that (today) this is ultimately handled 
as if:

@Entity
@Convert( attributeName="it", disableConversion=true )
public class Sub {
    ...
    @Convert( converter=Converter1.class )
    public String getIt() {
        ...
    }
}

Here, "the XML winning" (again, given today's commons-annotations code) 
does not mean that the conversion is being disabled.  Really it comes 
down to the reading of the spec section I quoted above.  Outside of the 
TCK testing for this, I think that we ought to say that the XML 
placement follows the same rules as the annotation placement and that 
they are treated equally.

Unless we want to start tracking the source of annotations (real 
annotations versus xml), which I think is what it would take to conform 
to the "letter of the law" defined in the spec.




On Fri 30 Aug 2013 09:06:33 AM CDT, Emmanuel Bernard wrote:
> Yes I get that but JPAOverriddenAnnotationReader is only about reading
> the XML and converting it into annotations.
>
> I understand that implementing the rules based on the annotations is
> more complex than annotation override.
>
> On Fri 2013-08-30  8:44, Steve Ebersole wrote:
>> Its not that easy.  This is not as simple as AttributeOverride.  The
>> rules here are much more complex (or convoluted, depending on your
>> perspective).  An AttributeOverride always overrides.  The is just
>> not the case here with converters.  Plus how AttributeOverride works
>> does not need to vary from one use case to another (basics,
>> composites, plurals).
>>
>>
>> On Fri 30 Aug 2013 07:47:36 AM CDT, Emmanuel Bernard wrote:
>>> On Fri 2013-08-30  6:27, Steve Ebersole wrote:
>>>>
>>>> On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
>>>>>>
>>>>>>
>>>>>> 2) The 'declaringClassName' passed in to SimpleValueBinder#setType
>>>>>> is Sub. So maybe we can leverage that. But
>>>>>> org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
>>>>>> (the main caller of this method) has explicit handle for null-ness
>>>>>> so that makes me nervous.
>>>>>>
>>>>>> Given the differing rules for resolving converter to use for basic
>>>>>> types, collections and composites and the fact that these
>>>>>> distinctions are already handled in the PropertyHolder hierarchy, I
>>>>>> think it would be better to handle those distinctions there. Either
>>>>>> adding a separate method to inject the converter to use (making sure
>>>>>> it is called before setType, ugh) or changing the signature of
>>>>>> setType to accept the converter to use.
>>>>>> PropertyBinder#makePropertyAndValue would then use
>>>>>> PropertyHolder#resolveAttributeConverter to pass what it needs to
>>>>>> pass.
>>>>>>
>>>>>> WDYT?
>>>>>
>>>>>
>>>>> Yes that makes sense to consolidate this logic in PropertyHolder. But I
>>>>> have to admit I failed to find an elegant algorithm and data structure
>>>>> to resolve the convert use cases you have described. All involved some
>>>>> back reading of annotations etc :(
>>>>
>>>> Depends what you mean "back-reading".  I planned on sifting through
>>>> the annotations as "resolve" is called.
>>>>
>>>>>
>>>>> BTW is it possible to have the illegal case by mean of mixing XML and
>>>>> annotation. ie you have the @Convert on the property and the disable
>>>>> facility at the class level in XML. Does the same rule apply?
>>>>> Because for sure the XML and the annotation are treated equally by
>>>>> commons annotation.
>>>> <quote>
>>>> The convert subelement is additive to any Convert or Converts
>>>> annotations on the entity. It
>>>> overrides any Convert annotation for the same attribute name. If a
>>>> convert subelement is present,
>>>> and attributes or subelements of that convert subelement are not
>>>> explicitly specified, their default
>>>> values are applied
>>>> </quote>
>>>>
>>>> My reading of that on your use-case is that we really should apply
>>>> the XML-defined converter.  But hiberate-commons-annotations simply
>>>> does not give us the information needed to be able to do that
>>>> properly.
>>>
>>> You can do that, you would code the logic in JPAOverriddenAnnotationReader in ORM Core.
>>> Check getAttributeOverrides / mergeAttributeOverrides as an example of
>>> how to read Java annotation, the XML "annotations" and merge the two as
>>> you please.