I might also recommend the JMS EG create an interface which extends ActivationSpec to define these properties and their types. It will still be loosely-typed from the user's perspective, but can make things easier at the Container/Connector level.
Something like this:
package javax.jms;
import javax.jms.Destination;
import javax.resource.spi.ActivationSpec;
public interface JmsActivationSpec extends ActivationSpec {
// could be an enum
public String getAcknowledgeMode();
public void setAcknowledgeMode(String acknowledgeMode) ;
public String getMessageSelector() ;
public void setMessageSelector(String messageSelector) ;
public Class<? extends Destination> getDestinationType() ;
public void setDestinationType(Class<? extends Destination> destinationType) ;
// could be an enum
public String getSubscriptionDurability() ;
public void setSubscriptionDurability(String subscriptionDurability) ;
public String getDestinationLookup() ;
public void setDestinationLookup(String destinationLookup) ;
public String getConnectionFactoryLookup() ;
public void setConnectionFactoryLookup(String connectionFactoryLookup) ;
public String getClientId() ;
public void setClientId(String clientId) ;
public String getSubscriptionName() ;
public void setSubscriptionName(String subscriptionName) ;
public String getShareSubscriptions() ;
public void setShareSubscriptions(String shareSubscriptions) ;
}
The properties could be javadoc'ed and people could referred to that for help using the activation config.
-David
On Jul 6, 2012, at 10:30 AM, David Blevins wrote:
> Disregard, clearly stated as activation config properties in the PDF.
>
> +1 from me.
>
>
> David
>
> On Jul 6, 2012, at 10:24 AM, David Blevins wrote:
>
>> I'm not in favor of adding 'messageDestinationJndiName' or 'messageDestinationLink' to @MessageDriven.
>>
>> The proposal uses a deprecated mime as something we should do going forward.
>>
>> These should be activation config properties like <message-destination-type> became the 'destinationType' activation config property.
>>
>> It's hard to argue that between these:
>>
>> <message-destination-type> (EJB 2.1, deprecated in EJB 3.0, replaced with activation-config)
>> <message-destination-jndi-name> (proposed addition)
>> <message-destination-link> (proposed addition)
>>
>> One of them should go in the activation config and the other two should be on @MessageDriven directly.
>>
>> What is the harm of keeping consistency with the mime setup in EJB 3.0?
>>
>>
>> -David
>>
>>
>> On Jul 5, 2012, at 6:10 PM, Marina Vatkina wrote:
>>
>>> Experts,
>>>
>>> This is the email and the revised proposal on alignment of EJB, JMS, and JCA specs in the MDB configuration areas.
>>>
>>> Please read carefully the email and the proposed changes and let me and Nigel (who is on the users alias) know if you agree with the proposal or not (and if not, the why).
>>>
>>> thanks,
>>> -marina
>>>
>>> -------- Original Message --------
>>> Subject: [jms-spec users] [jsr343-experts] Proposals for MDB and RA standardisation (JMS_SPEC-30,55,54,25,73)
>>> Date: Fri, 29 Jun 2012 18:59:23 +0100
>>> From: Nigel Deakin <nigel.deakin_at_oracle.com>
>>> Reply-To: jsr343-experts_at_jms-spec.java.net
>>> To: jsr343-experts_at_jms-spec.java.net
>>>
>>>
>>>
>>> This email covers a number of related issues, all covered in the attached document.
>>>
>>> Some time ago we discussed and agreed on a number of changes that we would like to see made to the EJB spec to standardise the way in which JMS MDBs were configured. Here are the JIRA issues:
>>>
>>> http://java.net/jira/browse/JMS_SPEC-30
>>> Define mandatory activation config properties for JMS MDBs
>>>
>>> http://java.net/jira/browse/JMS_SPEC-55
>>> Define a standard way to configure the connection factory used by a JMS MDB to consume messages
>>>
>>> http://java.net/jira/browse/JMS_SPEC-54
>>> Define a standard way to configure the destination on which a JMS MDB consumes messages
>>>
>>> I have spent quite a lot of time negotiating with the EJB spec lead about the details of these changes and have now come to provisional agreement, though these change have yet to be confirmed by the EJB EG. The attached document contains a summary of what we agreed. I would now like to bring these proposals back to the JMS EG for comments.
>>>
>>> Separately, also agreed in principle even longer ago that we should standardise the interface between a JMS provider and a Java EE application server by making it mandatory for a JMS vendor to provide a JCA resource adapter. Here is this JIRA issue:
>>>
>>> http://java.net/jira/browse/JMS_SPEC-25
>>> Standardise the interface between a JMS provider and a Java EE application server
>>>
>>> However if we're going to standardise on MDB configuration we also need to standardise on ActivationSpec properties. The attached document also contains some proposals to define a JMS resource adapter as part of the JMS specification. This essentially consists of moving the section on JMS resource adapter out of the JCA 1.6 spec, adding it to the JMS spec, and adding some additional properties.
>>>
>>> Finally, on 15th June I raised this new issue:
>>>
>>> http://java.net/jira/browse/JMS_SPEC-73
>>> Define how messages from a topic are delivered to clustered application server instances
>>>
>>> I made some provisional proposals to address this here
>>> http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2012-06/message/7
>>>
>>> I haven't received any comments on that email. However since these proposals involve the standardisation of an additional ActivationSpec property, and the container making varius pieces of information available to the resource adapter, I thought it helpful to combine these proposals within this document as well.
>>>
>>> So please have a look at the attached document and make any comments. I'm not setting a deadline for comments but it would be really helpful if you could have a look within the next week or so. If it's not obvious why I've made a particular proposal please do ask and I'll try to explain.
>>>
>>> I know we're approaching the vacation season, and it's the 4th July next Wednesday as well.
>>>
>>> If this EG is generally happy with this document I plan to turn this document (except for the parts that go into the EJB spec) into a new chapter for the JMS spec.
>>>
>>> Thanks,
>>>
>>> Nigel
>>>
>>>
>>>
>>>
>>> <MDBAndRAConfiguration.pdf>
>>
>