[JMS_SPEC-56] Enhance the EJB specification to support the delivery of messages in batches to MDBs Created: 08/Nov/11  Updated: 01/May/12  Resolved: 01/May/12

Status: Closed
Project: jms-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JMS_SPEC-36 Allow messages to be delivered asynch... Open
depends on EJB_SPEC-44 Enhance the EJB specification to supp... Resolved
Tags: eg, jms20-jsr345

 Description   

This is a request for changes to the EJB specification to support the asynchronous delivery of messages to a message-driven bean in batches.

This new feature is described in JMS_SPEC-36. To support this there will be a new listener interface javax.jms.BatchMessageListener, which provides the method onMessages(Message[] messages).

Where batch delivery is not required, the existing javax.jms.MessageListener interface and its method onMessage(Message message) will continue to be used as before.

The following changes to the EJB specification are suggested (references are to the EJB 3.1 specification)

Section 5.4.2 "The Required Message Listener Interface"


Change: "The message-driven bean class's implementation of the javax.jms.MessageListenerinterface distinguishes the message-driven bean as a JMS message-driven bean."

To: "The message-driven bean class's implementation of the javax.jms.MessageListener or javax.jms.BatchMessageListener interface distinguishes the message-driven bean as a JMS message-driven bean."

An additional node should be added to state that a JMS message-driven bean may implement either of these interfaces or both.

5.6.2 "Message-Driven Bean Class"


Change: "In the case of JMS, this is the javax.jms.MessageListener interface."

To: "In the case of JMS, this is either the javax.jms.MessageListener or javax.jms.BatchMessageListener interface."

13.6.3.2 "REQUIRED£


In all four places change: "onMessage method"

to: "onMessage or onMessages method"

21.3.5 "JMS 1.1 Requirements"


Change name of section to: "JMS 2.0 Requirements"

Change: "An implementation requiring the full EJB 3.1 API must include the JMS 1.1 extension"

To: "An implementation requiring the full EJB 3.2 API must include JMS 2.0"

In the fourth paragraph,

Change: "Enterprise beans must not call the javax.jms.MessageConsumer.setMessageListener or javax.jms.MessageConsumer.getMessageListener method."

To: "Enterprise beans must not call the javax.jms.MessageConsumer.setMessageListener, javax.jms.MessageConsumer.setBatchMessageListener, javax.jms.MessageConsumer.getMessageListener or javax.jms.MessageConsumer.getBatchMessageListener methods."

5.4.14 "Activation Configuration Properties"


This section introduces a list of activation configuration properties for JMS message-driven beans. An additional section should be inserted which describes the additional properties needed for batch delivery:

Insert new section: 5.4.<n> "Batch delivery" as follows:

If the JMS Message-driven bean implements the javax.jms.BatchMessageListener interface then the following activation configuration properties may be used to configure batch delivery:

  • batchSize: If set to greater than zero, messages will be delivered by calling the onMessages(Message[] messages) method. The bean class must implement javax.jms.BatchMessageListener. Messages will be delivered in batches of up to batchSize messages. The actual batch size used may be any value between one and the specified batchSize. It is invalid to specify a value greater than zero if the bean class does not implement javax.jms.BatchMessageListener.
  • batchTimeout: If batch delivery is used, this specifies the maximum number of milliseconds that the JMS provider may defer message delivery for in order to assemble a batch of messages that is as large as possible but no larger than the batch size.


 Comments   
Comment by Nigel Deakin [ 23/Nov/11 ]

This issue has now been forwarded to the EJB 3.2 expert group as EJB_SPEC-44. Please make further comments there, not here.

Comment by Nigel Deakin [ 01/May/12 ]

Following the decision to defer JMS_SPEC-36 (Allow messages to be delivered asynchronously in batches) I am going to close this issue. If changes are needed to the MDB specification in the future a new issue will be logged.

Comment by Nigel Deakin [ 01/May/12 ]

Closing as "Won'tFix" because that's the nearest resolution I can see to "withdrawn".





[JMS_SPEC-54] Define a standard way to configure the destination on which a JMS MDB consumes messages Created: 21/Oct/11  Updated: 20/Mar/13  Resolved: 07/Feb/13

Status: Resolved
Project: jms-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0FD, 2.0

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on CONNECTOR_SPEC-4 Clarify whether the ResourceAdapter.e... Resolved
blocks MQ-250 Implement JMSRA activation properties... Closed
Related
is related to JMS_SPEC-30 Define mandatory activation config pr... Resolved
is related to JMS_SPEC-55 Define a standard way to configure th... Resolved
Tags: eg, jms20-jsr345, pd20-added

 Description   

This is a request for the JMS and/or EJB specifications to improve the way in which specify how an application or deployer may specify the destination from which a JMS message-driven bean to receive messages. There are several significant omissions from the specification which need to be rectified.

Although MDBs are specified in the EJB specification, this request should be considered first by the JMS 2.0 expert group who may then want to raise it with the EJB 3.2 expert group.

Review of existing specification (EJB 3.1)

In the EJB 3.1 specification, Section 16.9 "Message Destination References" states that the destination used by a JMS message-driven bean can be specified using the <message-destination-link> element of the <message-driven> element in ejb-jar.xml:

<message-driven>
   <ejb-name>ExpenseProcessing</ejb-name>
   <ejb-class>com.wombat.empl.ExpenseProcessingBean</ejb-class>
   <messaging-type>javax.jms.MessageListener</messaging-type>
   ...
   <message-destination-type>javax.jms.Queue</message-destination-type>
   <message-destination-link>ExpenseProcessingQueue</message-destination-link>
   ...
</message-driven>

Issues with the existing specification

This raises the following questions:

1. What is <message-destination-link>?

The <message-destination-link> element defines the destination from which the MDB consumes messages in terms of a "message destination reference".

The purpose of "message destination references" is to allow an application which sends messages to a particular destination and also consumes from the same destination to inform the deployer of this fact without having to actually specify the name (or JNDI name) of the destination.

As stated above, a MDB can specify the "message destination reference" of the destination from which it consumes messages using a <message-destination-link> element under the <message-driven> element. Another component (e.g. a session bean or another MDB) can specify the destination to which it sends messages using a <message-destination-link> element under a <message-destination-ref> element. If these two elements contain the same string then the deployer knows they refer to the same queue or topic.

A message destination reference is not the JNDI name of the queue or topic. It is just a logical name. It can be mapped to an actual JNDI name using the <assembly-descriptor> element in ejb-jar.xml as follows:

Here's how ejb-jar.xml could be used to define a MDB as consuming messages from a "message destination reference" called MsgBeanInQueue which was mapped to a JNDI name jms/inboundQueue:

<ejb-jar>
  <enterprise-beans>
    <message-driven>
      <display-name>MDB1</display-name>
      <ejb-name>MessageBean</ejb-name>
      <messaging-type>javax.jms.MessageListener</messaging-type>
      <transaction-type>Container</transaction-type>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <message-destination-link>MsgBeanInQueue</message-destination-link>
    </message-driven>
  </enterprise-beans>
  <assembly-descriptor>
    <message-destination>
      <lookup-name>jms/inboundQueue</lookup-name>   <!---
      <message-destination-name>MsgBeanInQueue</message-destination-name>
    </message-destination>
  </assembly-descriptor>
</ejb-jar> 

A message destination reference can typically also be mapped to an actual JNDI name using the application-server-specific deployment descriptor, though by definition this is beyond the scope of the EJB specification.

2. Is that the only way you can define the destination on which a MDB consumes messages in ejb-jar.xml? Can you define its JNDI name directly without bothering with references?

No, the EJB specification doesn't mention any way to define the destination in ejb-jar.xml apart from using the <message-destination-link> element of ejb-jar.xml. In particular it doesn't define any way to define its JNDI name directly, analogous to using either the JNDI API or a @Resource(lookup="jms/foo") declaration for managed connections.

3. Can I define the message destination reference for a MDB using annotation?

No, there is equivalent to <message-destination-link> using annotation.

4. Can I define the JNDI name of the destination on which a MDB consumes messages directly using annotation?

No, there is no way to define this using annotation, analogous to using a @Resource(lookup="jms/foo") declaration when using the JMS API directly.

So, what seems to be missing?

A. As explained in (2) and (4) above, there isn't a standard way for MDB applications to short-circuit the use of message destination references and define the JNDI name of the destination from which a JMS message-driven bean consumes messages, either using ejb-jar.xml or annotations. This contrasts with EJBs which send messages, where the JNDI name of the destination can be specified in the MDB code using the JNDI API or a @Resource(lookup="jms/foo") declaration.

B. As explained in (3) above, there is no standard way for the application to define using annotation the "message destination reference" on which the JMS message-driven bean is consuming messages.

Proposals:

A. It is proposed that the <message-driven> element in ejb-jar.xml be extended to define an additional sub-element which can be used to specify the JNDI name of the destination from which a JMS message-driven mean consumes messages. A suggested element name is <message-destination-jndi-name>:

<ejb-jar>
  <display-name>Ejb1</display-name>
  <enterprise-beans>
    <message-driven>
      <display-name>MDB1</display-name>
      <ejb-name>MessageBean</ejb-name>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <message-destination-jndi-name>jms/inboundQueue<message-destination-jndi-name>
      ...

It might be asked why this needs to be defined by a new subelement of <message-driven> rather than, say, a new standard activation configuration property. The answer is that the way that the JNDI name is defined needs to be consistent with the way that the message destination reference is defined, which is by the <message-destination-link> subelement of <message-driven>

B. It is proposed that the equivalent annotation be a new attribute of the @MessageDriven annotation, called messageDestinationJndiName. For example:

@MessageDriven(messageDestinationJndiName="jms/inboundQueue")
public class MyMDB implements MessageListener {
....

C. It is proposed that the @MessageDriven annotation be extended to allow applications to define the "message destination reference" on which the JMS message-driven bean is consuming messages, using a new attribute messageDestinationLink"

@MessageDriven(messageDestinationLink="ExpenseProcessingQueue")
public class MyMDB implements MessageListener {
....


 Comments   
Comment by rdohna [ 25/Oct/11 ]

Linked these two issues

Comment by Nigel Deakin [ 25/Oct/11 ]

Corrected names of annotation attributes

Comment by Nigel Deakin [ 07/Nov/11 ]

Added tag jsr345 to identify that this issue requires changes to the EJB spec, not the JMS spec

Comment by Nigel Deakin [ 05/Dec/12 ]

The current proposal is to define a standard activation property destinationLookup.

However this is only possible if the connector spec can guarantee that the resource adapter will be able to perform the lookup in the endpointActivation call. I have logged CONNECTOR_SPEC-4 to request clarification .

Comment by Nigel Deakin [ 07/Feb/13 ]

Note that CONNECTOR_SPEC-4 is now resolved.

Comment by Nigel Deakin [ 07/Feb/13 ]

The JMS 2.0 and EJB 3.2 specifications now define a activation property destinationLookup. This is defined as follows (JMS 2.0 section 13.1 "MDB activation properties"):

Activation property Description
destinationLookup This property may be used to specify the lookup name of an administratively-defined javax.jms.Queue or javax.jms.Topic object which defines the JMS queue or topic from which the endpoint (message-driven bean) is to receive messages.

This issue can now be marked as resolved.





[JMS_SPEC-47] Deprecate domain-specific APIs and propose for removal Created: 15/Aug/11  Updated: 24/Feb/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: eg, pd20-underreview

 Description   

Summary

In version 1.0b of the JMS specification, applications had to use a completely separate set of interfaces when working with queues as they did when working with topics.

Specifically, applications working with queues had to use the interfaces QueueConnectionFactory, QueueConnection, QueueSession, QueueSender and QueueReceiver, whilst applications working with topics had to use the interfaces TopicConnectionFactory, TopicConnection, TopicSession, TopicPublisher and TopicSubscriber.

Although these two sets of interfaces shared common supertype interfaces ConnectionFactory, Connection, Session, MessageProducer and MessageConsumer, these were effectively abstract classes, and applications were forced to use the interfaces specific for the messaging domain (queue or topic) that they were using.

In version 1.1, new API methods were added to the common superclass, domain-independent, interfaces to allow them to be used directly by client applications. This offered a simpler programming model, and for first time allowed queues and topics to participate in the same local transaction, now that they could be accessed using the same session.

In JMS 1.1 all of the domain-specific interfaces were retained to provide backwards compatibility, but it was stated in Section 1.5 that "in the future, some of the domain-specific APIs may be deprecated".

For 2.0 it is time to take this to the next stage, and to formally announce that these interfaces are now deprecated and that they will be removed from a future version of the specification.

This would remove 15 interfaces from JMS and reduce the total number of interfaces by 34%, from 44 to 28.

Detail

This change would affect the following interfaces:

XAQueueConnection
XAQueueConnectionFactory
XAQueueSession
XATopicConnection
XATopicConnectionFactory
XATopicSession
QueueConnection
QueueConnectionFactory
QueueReceiver
QueueSender
QueueSession
TopicConnection
TopicConnectionFactory
TopicPublisher
TopicSession
TopicSubscriber

There would be two changes:

  • These interfaces would be formally marked as deprecated, by use of the @java.lang.Deprecated annotation. This would cause compilers to issue a warning when a deprecated method was used.
  • These interfaces would be formally marked in the specification as being "proposed for removal", with the expectation that they would be made optional in the next release.

There do not appear to be any binding policies on how to deprecate or remove classes from a Java EE API, which means that the final decision is up to the expert group. However the Java EE Specification, section EE.6.1.3 "6.1.3Pruned Java Technologies" (which discusses a different issue, that of removing entire technologies from Java EE), links to a Java SE policy described at http://mreinhold.org/blog/removing-features, which appears to be a suitable policy to offer.

That policy states that a particular version of a spec may state that a feature is "proposed for removal". This means that the following version can remove it.

However that policy also states that "removal" of a feature does not mean actually deleting it. Instead the feature will remain in the specification but will become optional. This means that implementers are not required to implement it. Its tests will remain in the TCK to allow those who decide to implement it to verify that it has been implemented correctly.

Other issues

Before making this change we should confirm that the "domain-independent" interfaces are a complete replacement for the "domain-specific" interfaces.

It has been noticed that Session.createDurableSubscriber() returns a TopicSubscriber, not a MessageConsumer. This looks to me like a mistake which would need to be fixed before we could remove TopicSubscriber. The solution would be for this method to return a MessageConsumer. Since this is a supertype of TopicSubscriber it should not break existing applications. (Edit: This has now been raised separately as JMS_SPEC-51 )






[JMS_SPEC-28] Clarify how the JMS provider should interact with Transaction Managers. Created: 06/Jul/11  Updated: 24/Feb/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: eg, pd20-underreview

 Description   

Clarify how the JMS provider should interact with Transaction Managers. In particular, the responsibilities of the JMS Provider, the TM and the App Server during recovery need to be clearly defined.

(This issue is a placeholder. More information about the ambiguities that need to be resolved will be added later)



 Comments   
Comment by cptmauli [ 06/Dec/11 ]

Please provide a way to specify explicitly when a JMS Message is sent.

Current situation (for instance JBoss 6, but others have the same problem):

  • a method updates the database and sends a JMS message (transactional)
  • the message is received and the same record is read from the database, but it will often still read the state before the update

Cause:

the JMS message is sent when the transaction manager decides that the commit is valid. That doesn't mean the actual database commit is now visible! This hurt us badly and we had to use the TransactionSynchronizationRegistry to work around this issue.

Solution:

The ideal solution would be if I could define the way when the message should be sent, I also would like to see that even beeing within a Transaction that I have the means to send a message non-transactional. Further it also should provide a way to send a message if a rollback occurs. A enum in the send method would be nice, something like NON_TRANSACTIONAL, DEFAULT, ON_COMMIT, ON_ROLLBACK, AFTER_COMMIT.

Comment by Nigel Deakin [ 08/Dec/11 ]

Can you explain the issue in more detail? You write

> the JMS message is sent when the transaction manager decides that the commit is valid.

It's up to the JMS provider to decide when to actually send the message from the producing client to the JMS server. It's fine to sent it immediately (when the application calls MessageProducer.send()). When the JMS server receives the message it can add it to the queue or topic but (assuming we're in a Java EE transaction) must not commit the operation.

> That doesn't mean the actual database commit is now visible!

When the transaction on the client is committed, the transaction manager will call commit() on the XAResource object provided by the JMS client. The JMS client will send the commit to the JMS server which will then commit the previous addition of the message to the queue or topic. The message will then become available for delivery to consumers.

> This hurt us badly and we had to use the TransactionSynchronizationRegistry to work around this issue.

Please provide more information to allow us to understand the problem.

Comment by Leos.Bitto [ 14/Dec/11 ]

> When the transaction on the client is committed, the transaction manager will call commit() on the XAResource object provided by the JMS client. The JMS client will send the commit to the JMS server which will then commit the previous addition of the message to the queue or topic. The message will then become available for delivery to consumers.

The problem is that after the message becomes available for delivery to the consumers, some consumer might start processing it and find old information in the database (for some record(s) identified by the data in the JMS message), because the commit() on the relevant database XAResource has not been processed yet (because it is processed after commit() of the JMS XAResource).

Some transaction managers allow ordering of the calls to commit() of the XAResources enlisted in the transaction, but this is an optional extenstion which is not required by JTA. See http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Transactions_Development_Guide/chap-Transactions_JTA_Programmers_Guide-Test.html#form-Transactions_JTA_Programmers_Guide-The_XAResource_Interface-Extended_XAResource_control for example. With the TransactionManager implementation from JBoss the possible workaround is to use the JMS XAResource wrapper which implements com.arjuna.ats.jta.resources.EndXAResource and therefore ensures that when the JMS message is sent, all the relevant database operations are already committed.

I am not sure whether this can be solved in JMS 2.0 only, though. It seems that this would require some cooperation from the JTA specification as well.

Comment by Nigel Deakin [ 14/Dec/11 ]

> The problem is that after the message becomes available for delivery to the consumers,
> some consumer might start processing it and find old information in the database
> (for some record(s) identified by the data in the JMS message),
> because the commit() on the relevant database XAResource has not been processed yet
> (because it is processed after commit() of the JMS XAResource).

The commit won't happen until onMessage() has returned, so how does the order in which the two resources in the transaction are committed make any difference?

Comment by Leos.Bitto [ 14/Dec/11 ]

1. onMessage() is called for processing of the JMS message #1
2. in onMessage() some data is updated in the database, based on the identification of this data from the JMS message #1
3. in onMessage() a JMS message #2 is sent, including the the identification (only a key, not the whole data) of the modified data in the database
4. onMessage() returns
5. XAResource#prepare is called for both the JDBC and JMS XAResources (the order is irrelevant)
6. XAResource#commit is called for the JMS XAResource, which removes the JMS message #1 from its queue, and sends the JMS message #2 to another queue
7. onMessage() is called in another thread for processing of the JMS message #2
8. data from the database is read, based on the data in the JMS message #2
9. problem is here - old data is read from the database!
10. in the original thread, XAResource#commit is called for the JDBC XAResource, which persists the updated data in the database, but it is too late now - another thread read wrong data already

Comment by Nigel Deakin [ 14/Dec/11 ]

I understand now. Thanks for the clarification.

This seems to be a general issue with the two-phase commit of two resources, where the updates to one resource are dependent on the updates to the other. As you suggested, this doesn't sound like something that can be tackled at the level of an individual resource manager such as JMS. It might be worth raising it with the Java EE 7 Platform Expert Group.

Comment by Leos.Bitto [ 15/Dec/11 ]

I am not sure whether this is the proper way of raising it, but here you are: http://java.net/jira/browse/JAVAEE_SPEC-1

Comment by Nigel Deakin [ 15/Dec/11 ]

That seems a good way to start (I note this is the first issue!).

I'll ping the Java EE spec leads to check they see it.

Any discussions on this will be automatically copied to, or take place on, the users' mailing list for that project so I would suggest subscribing there if you want to follow this up.





[JMS_SPEC-26] Decide on the future of the optional Chapter 8 API "JMS Application Server Facilities" Created: 06/Jul/11  Updated: 24/Feb/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: eg, pd20-underreview

 Description   

Chapter 8 of the JMS 1.1 specification, "JMS Application Server Facilities", defines an API for use by application servers. It has two parts:

  • API to allow concurrent processing of a subscription's messages: the interfaces ServerSession, ServerSessionPool, ConnectionConsumer and the methods Session.setMessageListener(), Session.getMessageListener() and Session.run().
  • API to support distributed (XA) transactions: XAConnectionFactory, XAConnection and XASession.

This API is optional and has no compliance tests.

Should this API be made mandatory, like the rest of the JMS spec, or should it be formally pruned from the spec?

This will partly depend on the outcome of http://java.net/jira/browse/JMS_SPEC-25 (Standardise the interface between a JMS provider and a Java EE application server). If it is decided that the interface between a JMS provider and a Java EE application server should use these interfaces (rather than the Java EE Connector API) then clearly they should become mandatory.

However, irrespective of the outcome of http://java.net/jira/browse/JMS_SPEC-25 it may be beneficial to keep this API and make it mandatory since that would

1. allow the creation of a generic JMS resource adapter that can work with any JMS 2.0 implementation, and
2. allow the creation of non-Java EE frameworks that provide services such as XA transactions and async delivery to multiple consumers, but which don't support the Java EE Connector Architecture

However these potential benefits need to be offset against the additional burden this may place on JMS vendors.

Note that if it is decided that these interfaces are not needed, they would not be deleted from the spec but remain in their current optional state, in accordance with chapter EE.6.1.3 "Pruned Java Technologies" of the Java EE 6 specification, perhaps with an explicit statement of why they are not needed.

If it is decided that these interfaces are still required then there some improvements may be required to clarify, say, the integration with the transaction manager.



 Comments   
Comment by Nigel Deakin [ 26/Jan/12 ]

It would be worth updating the Javadoc for the optional Chapter 8 API to explain that these classes and methods are primarily intended for use by application servers. This is obvious to anyone reading the spec, but for some reason isn't spelled out in the javadoc for methods like Session.setMessageListener().

Comment by Nigel Deakin [ 16/Feb/12 ]

I asked a colleague for their comments on the Chapter 8 API, and they replied as follows:

The getXAResource call has proved relatively robust for directly integrating foreign providers like Tibco, Sonic, and IBM MQ.

I think the main issue I have with it is the multi-RM problem: correctly fronting a logical RM that's actually backed by an independent set of RMs. In particular the problem is that we must currently somehow return the entire set of in-doubt transactions for all RMs in an entire cluster when "XAResource recover()" is called, even for component RMs that may not be running. We've all already discussed this at length. Currently, each provider must come up with some sort of internal solution on its own - but this isn't easy. Advancing one or all of the JTA, JCA, or JMS specs would help...

Another relatively smaller problem is that it would help to know when a vendor has thread-affinity requirements for a transaction life-cycle on the XAResource (IBM MQ). Or, alternatively, to harden the spec so that it's illegal to require thread affinity by default. It's a bit painful for a container to enforce such a requirement.

A secondary issue is the ConnectionConsumer API. It is complex and it's not entirely clear how it's supposed integrate with a foreign TM, and we've found no strong need to make use of it when integrating foreign providers.





Generated at Sun Jul 13 18:53:10 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.