See inline
> -----Original Message-----
> From: dev-return-5376-frank.kieviet=sun.com_at_glassfish.dev.java.net
> [mailto:dev-return-5376-frank.kieviet=sun.com_at_glassfish.dev.java.net] On
> Behalf Of Markus KARG
> Sent: Sunday, January 27, 2008 02:10
> To: dev_at_glassfish.dev.java.net
> Subject: Re: Non-JMS MDB needs JMS?
>
> Bill and Frank,
> >> You need to use a Glassfish specific deployment descriptor
> >> (sun-ejb-jar.xml)
> >> that will tell Glassfish to which resource adapter to bind your MDB.
> The
> >> parameter is called MID and is equal to the name of the resource
> >> adapter as
> >> it shows up in the glassfish console.
> > Isn't there enough information for GlassFish to match the resource
> > adapter
> > with the MDB without that deployment descriptor? I would think the
> > interface
> > implemented by the MDB could be matched with the interfaces supported
> > by the
> > resource adapter. What additional information is needed? (Obviously
> > if more than one resource adapter supported the same interface,
> > you would have to do something to resolve the ambiguity.)
> 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. 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,
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.)
>
> Thanks
> Markus
>
> --
> http://www.xing.com/go/invita/58469