users@genericjmsra.java.net

[Generic JMSRA-Users] Re: WebSphere Liberty Profile Beta

From: Larry McQueary <mcqueary_at_tibco.com>
Date: Wed, 20 Aug 2014 20:53:09 -0600

I'm moving rather slowly on packaging this up as an example, but I want to
describe the essential elements of making a simple JMS MDB work with
WebSphere Liberty Profile Beta (via GenericJMSRA). At the time of this
writing, the WebSphere App Server Liberty Profile is in its
August/September 2014 beta. The successive summer 2014 beta releases of
Liberty Profile have introduced support for JCA, MDB, and other
EJB-friendly features.

While I'm not providing a step-by-step setup procedure, I will provide some
notes on the essential elements that deviate somewhat from the GenericJMSRA
deployment examples I've seen for other app servers/versions (i.e. Sun and
JBoss):

1. Resource Adapter Configuration: For WAS/LP, configuration of the basic
adapter properties is through a <resource-adapter> element in the main app
server config file: server.xml. Here, you would specify the necessary JNDI-
or bean-based configuration parameters as described in the GenericJMSRA
documentation. There is no GUI provided for these custom properties, so
you'll be editing the XML directly in either Eclipse or your favorite XML
editor. The documentation of both GenericJMSRA and of WAS/LP are sufficient
to get you through this part.

2. Binding your MDB's ActivationSpec to the GenericJMSRA adapter: WAS
Liberty Profile requires the use of "jmsActivationSpec" in server.xml to
bind your MDB to the JCA adapter. Unfortunately, WAS/LP will not accept any
non-IBM ActivationConfig properties in this jmsActivationSpec. In our case
(with GenericJMSRA and a non-IBM JMS provider), the use of
"jmsActivationSpec" does nothing more than this simple binding. It is not
possible to specify any GenericJMSRA properties here. WAS/LP only
understands properties/attributes of its own messaging providers -- either
the internal JMS provider, "wasJms" or MQ JMS "wmqJms"). Ironically,
however, you MUST specify a property here, even a null one (as seen below),
in order to properly bind the MDB activationSpec to the adapter. Example:

<jmsActivationSpec id="sampleMDB/tibcosample/MessageBean">
   <GenericJMSRA/>
</jmsActivationSpec>

3. Configuring the ActivationSpec: Given the above, the only way to
configure your MDB's ActivationConfig properties is through Annotations in
the code. Unlike the resource-adapter-mid element in
sun-ejb-jar.xml/glassfish-ejb-jar.xml, the provider-specific deployment
descriptor/binding file for IBM (ibm-ejb-jar-bnd.xml) does NOT provide any
way for you to specify/override any activation-config-property. In fact,
although the <jca-adapter> element in this file allows you to specify a
non-default ActivationSpec binding name, it does nothing else that will
affect (in a positive way) the deployment of your MDB, therefore there
appears to be no benefit in using ibm-ejb-jar-bnd.xml at all for our
purposes here. It does have a destination-binding-name element, but there
is no way to bind this name to the ActivationSpec properties.

As I reflect on my experience with this, I'm trying to decide whether
anything I've learned would suggest a change to either GenericJMSRA or WAS
Liberty Profile would be warranted. I don't feel that I have the depth of
understanding of either in order to make a strong suggestion. I do feel
that WAS Liberty Profile imposes some IBM-centric assumptions on their
implementation of JCA support. The fact that a Message Driven Bean requires
a "jmsActivationSpec" (vs. an activationSpec) , and that the
"jmsActivationSpec", in turn, only supports configuration of IBM JMS
activation config properties (Liberty messaging or MQ), puts JCA connectors
for external JMS providers at a distinct disadvantage, eliminating any
deployment-time configurability.

If I take this up with IBM (which I will), I suspect I'll get the response
"well, WAS Liberty Profile only supports Liberty embedded JMS, EIS, or MQ"
-- but that misses the point of having a JCA resource adapter altogether,
doesn't it?

I hope this information is of help to others. I'll post my working example
to GitHub and link it here once it's done.

If anyone can suggest something I've missed or gotten wrong, I'm all ears.

Cheers,
Larry M.




On Thu, Aug 7, 2014 at 4:39 AM, Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:

> Larry,
>
> Once you have got this all working (and assuming it does indeed work to
> your satisfaction) it would indeed be very helpful if you could write up
> what you have learned. We could either add it to genericjmsra.java.net or
> add a link to an article hosted elsewhere.
>
> Thanks,
>
> Nigel
>
>
> On 06/08/2014 21:49, Larry McQueary wrote:
>
>> Nigel,
>>
>> Very kind of you to respond. I hear you might know a thing or two about
>> JMS! ;-)
>>
>> I'm happy to report that the source of my issues was chiefly, as you
>> suggest, in getting the WebSphere-specific bindings
>> right. IBM's documentation is formidable, in both positive and negative
>> ways. It lays out quite a bit of information
>> about both the standard bindings and non-standard bindings, but doesn't
>> give a lot of help understanding in which cases
>> one applies vs. the other. Further, much of WebSphere's JMS JCA and MDB
>> related documentation assumes you're using
>> either MQ or WebSphere's internal messaging (with even more non-standard
>> binding/notation!), therefore the examples
>> require some translation as well.
>>
>> Once I sorted out the fact that <jmsActivationSpec> is the exclusive way
>> to specify the binding parameters in the
>> server.xml, and sorted out the non-standard notation in
>> ibm-ejb-jar-bnd.xml, I was able to drive my request-reply MDB
>> via GenericJMSRA (and EMS) without issue.
>>
>> As the steps for configuring for WebSphere Liberty Profile are a bit
>> different from those for JBoss, SJSAS/GlassFish,
>> and even WebSphere "Full" Profile, I will submit my configuration steps
>> in a separate posting so they can (I hope) be
>> included in the site and/or SVN.
>>
>> Thanks again for the thoughtful response.
>>
>> Cheers,
>> Larry
>>
>>
>>
>> On Wed, Aug 6, 2014 at 5:24 AM, Nigel Deakin <nigel.deakin_at_oracle.com
>> <mailto:nigel.deakin_at_oracle.com>> wrote:
>>
>> Larry,
>>
>> I don't have any experience of the combination of app server and JMS
>> provider you are trying to use. However
>>
>>
>> On 31/07/2014 02:03, mcqueary_at_tibco.com <mailto:mcqueary_at_tibco.com>
>> wrote:
>>
>> I am using the genericra.rar package as provided, with no
>> modifications
>> (other than adding my provider jars to it), and attempting to
>> configure
>> via the MessageDriven/__ActivationConfigProperty annotations in
>> my MDB,
>>
>> along with the resourceAdapter and activationSpec elements of my
>> server.xml. I can't seem to concoct the right activationSpec, or
>> possibly my resourceAdapter element/properties are wrong. I have
>> tried
>> lots of things I see in the IBM documentation, but generally my
>> results
>> are that a) I enter a property in the activationSpec that the
>> server
>> doesn't understand (resulting in the activation spec being
>> ignored/),
>> or I enter an "empty" property, resulting in a
>> NullPointerException/invalid property exception.
>>
>>
>> The EJB spec defines that you can set activation properties either
>> using <activation-config> elements in ejb-jar.xml
>> or using @MessageDriven(__activationConfig = ... on the bean class.
>> This should work for any app server.
>>
>>
>> The app server should pass these straight through to the resource
>> adapter.
>>
>> Note however that the way you actually specify that a given MDB
>> should use a particular resource adapter is always
>> non-standard and will be in some IBM-specific descriptor. This will
>> be in the WebSphere docs. It looks as if you
>> have got this part working. If you have you should see GenericJMSRA
>> startup messages in the log when you start your
>> application (and GenericJMSRA error messages if it fails).
>>
>> An IBM-specific descriptor may also provide an alternative,
>> non-standard way to specify activation properties. I
>> think <jmsActivationSpec> is an example of this. Again this will be
>> in the WebSphere docs, and would use some other
>> file than ejb-jar.xml. I didn't see mention of <activationSpec>.
>>
>> Obviously, once you have worked out how to pass activation properties
>> to GenericJMSRA the next step is to work out
>> what they should be set to...
>>
>> Hope this is of some limited help.
>>
>> Nigel
>>
>>
>>