> 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.
>
As the design lead of a mid-range ISV (we are selling software to end
users, packaged as .ear files) I need to tell you that for ISVs this is
completely not true. We have very big problems with the fact that still
virtually all app servers cannot deploy an .ear without getting
vendor-specific DDs packed into the .ear's contents.
As a result, users call our hotlines and tell us a lot of deployment
problems. Our hotlines then need to learn a lot of different app server
specific things. This leads to costs, and costs is not a nice thing.
Also, we do not talk about A, B and C. We have 1100 enterprise
customers. You might can imagine that virtally all app servers existing
on this earth might be used by them. So we talk about N products, not 3
products. Supporting N products is really, really problematic for us.
Please, in the name of all ISVs on this world, provide a deployment that
does not need any vendor specific things.
Thanks
Markus
> 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
>>
>
>
>
> ---------------------------------------------------------------------
> 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