Hi Markus,
I agree that using appserver specific deployment descriptors is not quite an
ideal solution. But in practice the situation with appserver specific
deployment descriptors may still be workable: if you support application
servers A, B and C, you can always package the deployment descriptors for A,
B, and C in your EJB. The name of a RAR is typically fixed, so there rarely
would be a need to modify the deployment descriptors at deployment time.
Frank
> -----Original Message-----
> From: dev-return-5377-frank.kieviet=sun.com_at_glassfish.dev.java.net
> [mailto:dev-return-5377-frank.kieviet=sun.com_at_glassfish.dev.java.net] On
> Behalf Of Markus KARG
> Sent: Sunday, January 27, 2008 02:23
> To: dev_at_glassfish.dev.java.net
> Subject: Re: Non-JMS MDB needs JMS?
>
>
> > 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