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.
>>> > >>>
>>> >
>