Hi Markus
>>> [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.
We were also thinking that having more than 2 non-JMS RAs supporting
the same message listener was not really corner-case. For example,
take two RAs that supports CCI MessageListener. If we consider JMS
RAs, the situations is even more problematic, as we have atleast two
RAs available with GlassFish that supports JMS MDBs (jmsra and Generic
JMS RA). We also have users deploying MoM provider RAs. So it is not
uncommon to have multiple RAs supporting the same message listener
interface.
The best solution (albeit long term) would be to introduce an optional
annotation element to javax.ejb.MessageDriven to support linking of
the MDB to a resource-adapter, thereby enabling a user to provide an
archive that does not need to bundle a vendor DD to describe the link
to the RA.
>>> 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
However, as you and Bill have explained, this solution too would work
for the short term in GlassFish atleast (When there is only deployed
RA in the domain, that supports a non-JMS message listener interface,
auto-generate a sun-ejb-jar.xml on deployment pointing to that RA). I
have raised an enhancement request [1] for this.
Thanks
--Siva.
[1]
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4043
Markus KARG wrote:
> see inline