>>>> [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.
> 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.
Yes that is not uncommon. But I in the case that this discussion started
with -- a pretty proprietary listener -- it makes really no sense to any
user that he must manually configure the linkage. That is the main point
this discussion goes about.
> 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.
Well, actually I see a difference in discussion what to do in mid term
in GlassFish, and what to do in long term in the spec. In GlassFish, I'd
like to vote for the automatic stuff like it was described by me and
Bill ("if there is only one RA, take it automatically, and remember the
decision for the time when there is a second one"). In the spec, I'd
like to see both, a mandatory part (some kind of mapping annotation that
ALL vendors have to implement) and an optional part (some kind of
automatic solution like the one described above). So the users can rely
on partability, and the server vendors can produce nice proprietary
features ontop.
>>>> 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 for raising that request, I really appreciate that. :-)
Markus
>
> Thanks
> --Siva.
> [1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=4043
>
> Markus KARG wrote:
>> see inline
>
> ---------------------------------------------------------------------
> 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