> One of the problems of using the interface the MDB requires to find a
> resource adapter, may lead to surprises for the user: the deployment of
> another adapter with the same interface may lead to the sudden need to
> resolve ambiguities.
>
In my particular situation that is not the case, since my RA and my MDB
are the sole items running currently. Unless there really is a problem,
GF should not enforce additional information.
> BTW, having multiple adapters with the same interface is not uncommon by the
> way.
>
That is true and as soon as that is the case, I agree that there must be
a solution how to tell GF what MDBs link to what RAs. But the vendor
specific DD is not the best solution I think: It enforces to change the
package. That is not nice. I am working for an ISV and we do not like
the idea that our customers have to unpack our JARs to add
vendor-specific DDs. There should be a vendor-transparent solution, like
using annotations or the ejb-jar.xml file, or (my favourite) actively
asking at deployment (like admin console could deploy but disable the
MDB, providing a field on the UI where the admin can pick the actual RA
from a selection list).
In fact, I think that JSR 88 could solve that. If there would be a good
tool (like InstallShield) for JSR 88, the UI could just provide a UI
with the possible links and tell the server which one to use. The server
could store the answer for later redeployment. That is much more
vendor-transparent und user friendly. :-) But besides the one that I
started years ago on source forge, I do not know ANY graphical JSR 88
tool... :-(
> Annotations could be used instead of the MID field in the deployment
> descriptor. The mappedName element in @MessageDriven is implementation
> dependent, and in Glassfish it is used to denote what JMS destination the
> MDB should read from. However, this information can also be specified in the
> parameters of the activationspec, i.e. the activationConfig element in
> @MessageDriven.
>
> If you would want to do away with the deployment descriptor completely, the
> annotations should allow for elements to denote common parameters. E.g. all
> EE implementations have parameters for bean pool sizes. Extra elements could
> be invented, or a generic mechanism could be used. This generic mechanism
> could be done similar to the activatonConfig element, i.e. an arbitrary
> number of arbitrarily named key-value pairs can be specified. The generic
> mechanism can also be used to specify EE-implementation-specific
> configuration parameters, such as bean pool resize quantities, etc.
>
>
I agree with you that in Java EE 6 this topic should be covered in a
vendor-transparent way. Bill, I think the best future solution is that
there is an annotation that solves the ambiguities, and that is working
in the same way for SBs and MDBs (because the same problem can happen in
case that I define a resource interface to inject that in fact is
implemented by two resource classes). That way, the programmer would
have the choice to define a default link annotation in the code, while
the deployer still could override it using ejb-jar.xml. But the
information definitively must be found in a standard way, not in a
vendor specific way. ISVs do not like vendor specific additions, neither
in the code, nor in the packages.
Thanks
Markus
>> -----Original Message-----
>> From: dev-return-5373-frank.kieviet=sun.com_at_glassfish.dev.java.net
>> [mailto:dev-return-5373-frank.kieviet=sun.com_at_glassfish.dev.java.net] On
>> Behalf Of Bill Shannon
>> Sent: Saturday, January 26, 2008 15:09
>> To: dev_at_glassfish.dev.java.net
>> Subject: Re: Non-JMS MDB needs JMS?
>>
>> Frank Kieviet wrote:
>>
>>> Markus,
>>>
>>> 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.)
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
>
> ---------------------------------------------------------------------
> 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