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