So what about XML overrides? Here we have the same concern. Consider:
@Entity
public class Person {
...
@Convert( converter=FirstNameConverter.class )
public String firstName;
}
In terms of XML, the XSD gives users a choice:
<entity class="Person">
<convert attributeName="firstName" disableConversion="true"/>
</entity>
or:
<entity class="Person">
<attributes>
<basic name="firstName">
<convert disableConversion="true"/>
</basic>
</attributes>
</entity>
So is the first form treated as an error? Like we do if they had said:
@Entity
@Convert( attributeName="firstName", disableConversion=true )
class Person{
...
@Convert( converter=FirstNameConverter.class )
String firstName;
}
In regards to this form (child of <entity/>, section 12.2.3.16), the
spec does specifically say:
<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...
</quote>
But this was written before the situations being discussed here were
considered.
On Thu 22 Aug 2013 01:47:56 PM CDT, Linda DeMichiel wrote:
>
> I agree with what has been said in this discussion so far. I will
> flag this
> as an errata to be clarified in the next draft of the spec.
>
> -Linda
>
>
> On 8/22/2013 10:03 AM, gordon yorke wrote:
>>
>> Example 1 should be an error case because the @Convert is being
>> specified at effectively the same level.
>> --Gordon
>>
>> On 22/08/2013 1:54 PM, Steve Ebersole wrote:
>>>
>>> Yeah, I totally agree that these should override in the embedded
>>> case. That makes the most sense. To me its a matter
>>> of the more specific context. The problem for me is that, in my (1)
>>> the local Convert is actually the more specific
>>> context.
>>>
>>> On Thu 22 Aug 2013 11:42:15 AM CDT, Kevin Sutter wrote:
>>>>
>>>> Hi,
>>>> In section 11.1.10, there is this statement:
>>>>
>>>> "The Convert annotation may be applied to an entity class that extends
>>>> a mapped superclass to specify
>>>> or override a conversion mapping for an inherited basic or embedded
>>>> attribute."
>>>>
>>>> It's close to clarifying your (2) example, except you are not using a
>>>> mapped superclass. But, it does indicate that the @Convert at the
>>>> Entity level overrides the embedded attribute...
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> Kevin Sutter
>>>>
>>>>
>>>>
>>>> gordon yorke <gordon.yorke_at_oracle.com> wrote on 08/22/2013 09:53:14
>>>> AM:
>>>>
>>>> > From: gordon yorke <gordon.yorke_at_oracle.com>
>>>> > To: jsr338-experts_at_jpa-spec.java.net,
>>>> > Date: 08/22/2013 09:55 AM
>>>> > Subject: [jsr338-experts] Re: @Convert precedence
>>>> >
>>>> > I do not think it applies in this case either, I was just
>>>> pointing out
>>>> > the only place in the specification that mentions configuring a
>>>> > duplicate @Convert on the same attribute. The only other
>>>> reference to
>>>> > multiple converters for the same attribute is in the
>>>> > @Converter(autoApply) flag and in that case an @Convert is
>>>> required to
>>>> > specify which converter is used.
>>>> >
>>>> > --Gordon
>>>> >
>>>> > On 22/08/2013 11:45 AM, Steve Ebersole wrote:
>>>> > > Ah, I found it... 11.1.11 Converts Annotation
>>>> > >
>>>> > > I am not sure that is really talking about the situation I
>>>> described,
>>>> > > or maybe it is just misplaced. My examples are not using
>>>> @Converts.
>>>> > >
>>>> > >
>>>> > > On Thu 22 Aug 2013 09:43:33 AM CDT, Steve Ebersole wrote:
>>>> > >> Thanks for the reply Gordon. Where did you find that in the
>>>> spec? I
>>>> > >> did a search on that quote and found no matches.
>>>> > >>
>>>> > >> On Thu 22 Aug 2013 09:38:54 AM CDT, gordon yorke wrote:
>>>> > >>> Hello Steve,
>>>> > >>> The specification says in reference to @Converts that "Multiple
>>>> > >>> converters must not be applied to the same basic attribute."
>>>> but in
>>>> > >>> this case it makes sense to have the convert on the Embedded
>>>> attribute
>>>> > >>> override the convert within the Embeddable.
>>>> > >>> --Gordon
>>>> > >>>
>>>> > >>> On 22/08/2013 11:09 AM, Steve Ebersole wrote:
>>>> > >>>> I could not find mention of this in the spec so wanted to
>>>> start a
>>>> > >>>> discussion within the group. The concern is what to do when
>>>> multiple
>>>> > >>>> @Convert definitions can apply to a given attribute. If the
>>>> spec
>>>> > >>>> does cover this, I apologize; if so, could someone point out
>>>> the
>>>> > >>>> section?
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> 2 examples:
>>>> > >>>>
>>>> > >>>> 1) non-path
>>>> > >>>>
>>>> > >>>> @Entity
>>>> > >>>> @Convert( attributeName="firstName",
>>>> converter=FNameConverter.class )
>>>> > >>>> class Person{
>>>> > >>>> ...
>>>> > >>>> @Convert( converter=FirstNameConverter.class )
>>>> > >>>> String firstName;
>>>> > >>>> }
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> 2) path
>>>> > >>>>
>>>> > >>>> @Entity
>>>> > >>>> @Convert( attributeName="homeAddress.city",
>>>> > >>>> converter=HomeAddressCityConverter.class )
>>>> > >>>> class Person {
>>>> > >>>> ...
>>>> > >>>> @Embedded
>>>> > >>>> Address homeAddress;
>>>> > >>>> }
>>>> > >>>>
>>>> > >>>> @Embeddable
>>>> > >>>> class Address {
>>>> > >>>> ...
>>>> > >>>> @Convert( converter=CityConverter.class )
>>>> > >>>> String city;
>>>> > >>>> }
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> In (2) I think it is clearly better to apply
>>>> > >>>> HomeAddressCityConverter. But in (1) I think it is less
>>>> clear cut;
>>>> > >>>> there, personally, I'd think FirstNameConverter would be
>>>> applied.
>>>> > >>>> But not sure it makes sense to have different precedence rules.
>>>> > >>>
>>>> >
>>>
>>