see inline
>> I completely agree with Bill. As you might expect, my intention is not
>> only to get my MDB to work, but in the second level to discuss the still
>> needed vendor specific stuff. Actually I have exactly the same opinion
>> as Bill: As long as on my GF instance there is nothing running but
>> solely my RA and MDB, and since the MDB implements the only interface
>> that is declared by the RA, the current situation is absolutely
>> unambiguous. The target of EJB 3 was "convention over configuration", so
>> the reference implementation should not force people to provide
>> information if not absolutely needed. I agree that there could be
>> situations where there is no other choice, like having two RAs exporting
>> the same interface. But in my particular situation that is not the case,
>> so GF should be able to work without that vendor specific DD.
>>
> [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". :-)
Certainly no more working suddenly is not nice, and is not what I intend
to have.
> Say that you have successfully
> deployed a few EJBs that all use RAR 1 and that Glassfish bound the EJBs to
> RAR 1 by comparing interfaces. Now say that a few weeks later, you deploy
> RAR 2 that uses the same interfaces. Say that the server is restarted:
> suddenly the EJBs can no longer be unambiguously bound to RAR 1 or RAR 2,
>
Why? The user was satisfied with the old behaviour, so Glassfish could
just make notes on its internal config to know that when rebooting the
old link shall get re-established. This would be straightforward. If the
user wants to use another RA, he can use the admin console to change links.
> and a startup failure of the previously successfully deployed EJBs will
> occur. This may be surprising to the admin since he cannot readily correlate
> deployment of RAR 2 to the failure in the previously successfully deployed
> EJBs.
>
> (To be fair, there are other situations, especially with respect to
> classloading, where the deployment of a new RAR may affect previously
> successfully deployed EJBs.)
>
Regards
Markus
>
>
>> Thanks
>> Markus
>>
>> --
>> http://www.xing.com/go/invita/58469
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
--
http://www.xing.com/go/invita/58469