Markus KARG wrote:
>
>>>>> [fkieviet] I respectfully disagree with this: a solution that "through
>>>>> magic" works in most cases but not in all cases, or suddenly may stop
>>>>> working, is worse than no solution at all.
>>>> I need to disagree. This kind of "magic" is everywhere in EJB 3.
>>>> There are a lot of things that work behind the curtain in a vendor
>>>> specific way. For example, @GeneratedValue by default uses AUTO, and
>>>> what AUTO means is left open in the spec. The spec just says, it
>>>> must do "something", and the user can rely on getting a generated
>>>> value "somehow". In fact, "convention over configuration" is very
>>>> popular and people love getting things done "by magic". :-)
>> I agree that convention over configuration is a good thing, but
>> however, as I had pointed earlier, this "convention" is non-portable
>> and hence something that users wouldn't want to assume or rely upon.
> The @GeneratedValue(AUTO) decision that GlassFish / TopLink internally
> does is also not portable, since GlassFish might decide for TABLE while
> another vendor decides for IDENTITY. So I do not see why it is OK with
> the AUTO decision but it shall be a problem with the RA decision. I do
> not see any difference.
Sorry to be a nitpick, but what I meant was that the "convention" that
all application servers could do the RA binding through the mappedName
is not mentioned in the specification (as against @GeneratedValue
where atleast there is a guidance in the spec that there would be a
generated value and leaves the generation logic to the implementation).
Thanks
--Siva.