users@jms-spec.java.net

[jms-spec users] Issue I18: Legacy MessageListener and _at_JMSListener compatibility

From: David Blevins <dblevins_at_tomitribe.com>
Date: Tue, 4 Aug 2015 20:54:37 -0700

Pretty clear I'm never going to have time to address the entire manifesto of discussion points in one shot. Here's me attempting to address them one at a time as time permits. I see little feedback in general, so hopefully smaller chunks of digestible bits is easier for others as well. I hope I can give at least more consistent feedback in chunks.

Now on point...

This may be the wrong time to come to decision, but I'm looking through the API and options and wondering if it is a good idea to mix the legacy MDB API and new annotation approach.

The specific concern is the duplication and potential for conflict between the activation config and the annotations themselves.

 - Conflict: What to do if they disagree on destination name or destination type?

 - Precedence: If we set defaults in the annotation a user applies to onMessage and there is an explicit value in the activation config, which wins?

I realize of course, this possibility exists for the new MDB API regardless as the ActivationConfigProperty[] bucket of the @MessageDriven annotation still exists and the user might fill it in creating the potential for conflict even though MessageListener is not implemented.

Seems we have just a few choices:

 1. Use of Annotations and ActivationConfig are either/or

    a. only JMSMessageDrivenBean can use the annotation approach

    b. either JMSMessageDrivenBean or MessageListener can use the annotations as long as it is done without ActivationConfig use

 2. Define a clear rule for mixed use. This rule could be:

    a. Annotations, including annotation defaults, always win

    b. Activation Config Properties always win (we'd never do that, but presented for completeness)

    c. Deployment error on conflict

If you had asked me 4 years ago which was my preference, I might have said 2.a.

However, now as an employer I question the cost involved in writing TCK tests to cover the mixed cases for something like 2.a especially considering it is effectively a stop-gap. The benefit will be short-term, however the weight on compliance and the TCK will be long-term.

What thoughts do others have?


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com