dev@glassfish.java.net

Re: Non-JMS MDB needs JMS?

From: Sivakumar Thyagarajan <Sivakumar.Thyagarajan_at_Sun.COM>
Date: Mon, 28 Jan 2008 19:55:40 +0530

Hi Bill/Frank/Mark

If the goal is to remove the need for a vendor-specific DD, there was
  a suggestion discussed earlier during the GlassFish v1 days, that we
could use mappedName to specify the resource-adapter to be associated
with the MDB for non-JMS MDBs. (Remember that the mappedName is used
to specify the JMS destination JNDI name for JMS MDBs that use the
bundled JMS provider). The mappedName is product dependent and we
could choose it to mean what we want. Would this work?

We had felt then, that having two distinct meanings for an attribute
would be confusing and felt that mandating non-JMS MDBs to be bundled
with a sun-ejb-jar.xml was a fair compromise. We felt it was more
important to provide ease-of-use for the majority of our MDB
deployments (ie JMS MDBs using the bundled JMS RA)

Like Frank, I am wary of "intelligently" choosing bindings based on
runtime configuration.

However, it should be noted, that both approaches (mappedName and
deriving ra-mid based on installed RAs) are non-portable.

Thanks
--Siva.

Bill Shannon wrote:
> Frank Kieviet wrote:
>>> Why can't the binding decision be recorded at deployment time so that it
>>> can only fail as above when the app is redeployed?
>> That's certainly possible. Still, it'll be surprising to an admin that an
>> application suddenly causes a deployment error because he or someone else
>> had deployed another resource adapter.
>
> My guess is that it would be very infrequent. And of course the error
> message should clearly describe the problem. Seems like a reasonable
> compromise to make the common case easier.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>