Nigel,
On Wed, Mar 6, 2013 at 9:06 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> John,
>
>
> On 06/03/2013 13:27, John D. Ament wrote:
>
> Well, my general opinion is that we shouldn't be blocking callback type
> methods in an EE/Web container, instead providing a way to look up a
> business object (CDI, EJB) and call a method there that has an appropriate
> method signature. But we cannot at this time, may be something we dig into
> further in JMS 2.next.
>
>
> I think the biggest issue is supporting async send in a XA transaction.
> But if we can resolve this and the other issues mentioned I have no
> objection to trying to remove restrictions in the future.
>
>
Actually, I think it's the threading issue more than transactions. Or
perhaps they're one in the same, just with different symptoms.
>
>
> Anyways, I'm good with this. I'd prefer we block calling setAsync
> rather than blocking calling send later.
>
>
> Thanks.
>
>
>
> It is an interesting issue though, since I think most JMS providers
> don't currently block the methods, instead we're treating it more like it's
> not guaranteed to work across containers. JMS providers conceptually leave
> these issues up to the app server, but the app server may not care to block
> them.
>
>
> I can't say I'm happy with the lack of guarantee here - I was just
> following what the existing Java EE and EJB spec says for methods such as
> MessageConsumer.setMessageListener, which is that these methods "may only
> be used by application components executing in the application client
> container" and that the container "may throw a JMSException...". (Java EE 6
> spec section EE 6.7)
>
> I suspect the reason for the word "may" here is because there was no
> standard way for JMS clients to discover whether they are running in a Java
> EE web or EJB container (as opposed to the Java EE application client
> container or Java SE).
>
> However Java EE 7 now provides a way for an application (or JMS client) to
> discover whether it is running in the application client (via JNDI), so it
> may be possible to make enforcing these restrictions mandatory in a future
> version. I believe the current wording make it clear that calling these
> methods in a Java EE web or EJB container is never valid and is therefore
> an application error, even if it does not cause the JMS provider to throw
> an exception.
>
We may be looking at it from two sides of the coin here. I'd prefer if the
application server didn't want to throw an exception and instead allowed
the JMS provider to work the same in container and out of container. The
spec does allow for this ambiguity though, since the word is "may" rather
than "shall"
>
>
> Nigel
>
>
>
> John
>
>
> On Wed, Mar 6, 2013 at 7:25 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
>
>> (This is a minor spec/API update which clarifies the restriction on the
>> use of async send in a Java EE web or EJB container)
>>
>> In the draft JMS 2.0 specification, section 7.3.5 "Restrictions on usage
>> in Java EE" states that
>>
>> "An asynchronous send is not permitted in a Java EE EJB or web container.
>> If the application component violates this restriction the send method may
>> throw a JMSException or JMSRuntimeException (depending on the method
>> signature)."
>>
>> The same text can be found in the API docs for
>> MessageProducer.send(message, completionListener)
>> MessageProducer.send(message, deliveryMode, priority, timeToLive,
>> completionListener)
>> MessageProducer.send(destination, message, completionListener)
>> MessageProducer.send(destination, message, deliveryMode, priority,
>> timeToLive, completionListener)
>>
>> and for
>> JMSProducer.setAsync(completionListener)
>>
>> If you've forgotten why we're imposing this restriction, I've summarised
>> it on this wiki page
>>
>> http://java.net/projects/jms-spec/pages/JMS20ReasonsFAQ#Why_is_asynchronous_send_not_permitted_in_a_Java_EE_web_or_EJB_container
>> ?
>> (This text isn't in the spec, but we could add it if people think it
>> would be helpful)
>>
>> There are two things I would like to clarify:
>>
>> 1. Is there a restriction on calling JMSProducer.setAsync in a Java EE
>> EJB or web container? The wording above implies that this is perfectly
>> valid so long as the application doesn't subsequently call send(). This
>> needs to be clarified in both the spec and API docs.
>>
>> 2. The list of prohibited methods in section 12.2 "Restrictions on the
>> use of JMS API in the Java EE web or EJB container" needs to be updated to
>> include the methods related to async send.
>>
>> Let us consider (1). I think allowing JMSProducer.setAsync, but
>> prohibiting a subsequent call to JMSProducer.send, is simply confusing.
>> When I drafted the existing text I was certain that an async send should
>> not be permitted in a Java EE web or EJB container (for the reasons linked
>> to above) but I had not thought deeply about exactly what this meant in
>> terms of banned methods. So the existing wording is not deliberate.
>>
>> I propose we clarify this and state that JMSProducer.setAsync must not be
>> called in a Java EE web or EJB container. If an application violates this
>> restriction then this method may throw a JMSRuntimeException.
>>
>> (Although this method is definitely prohibited, I propose keeping it
>> optional whether the JMS provider enforces this with an exception, since
>> that is consistent with all the other methods which are prohibited in the
>> Java EE web or EJB container. This also has the benefit of not requiring
>> any last-minute changes to the RI or compatibility tests.
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------
>> PROPOSAL: 7.3.5. Restrictions on usage in Java EE (this is part of
>> section 7.3 "Asynchronous send")
>> Proposed new text:
>>
>> An asynchronous send is not permitted in a Java EE EJB or web container.
>>
>> The following methods must therefore not be used in a Java EE web or EJB
>> container:
>>
>> * javax.jms.Session method send(Message message, CompletionListener
>> completionListener)
>> * javax.jms.Session method send(Message message, int deliveryMode, int
>> priority, long timeToLive, CompletionListener completionListener)
>> * javax.jms.Session method send(Destination destination, Message message,
>> CompletionListener completionListener)
>> * javax.jms.Session method send(Destination destination, Message message,
>> int deliveryMode, int priority, long timeToLive, CompletionListener
>> completionListener)
>> * javax.jms.JMSProducer method setAsync(CompletionListener
>> completionListener)
>>
>> All the methods listed in this section may throw a javax.jms.JMSException
>> (if allowed by the method) or a javax.jms.JMSRuntimeException (if not) when
>> called by an application running in the Java EE web or EJB container. This
>> is recommended but not required.
>>
>> ----------------------------------------------------------------------------------------------------------------------
>>
>> PROPOSAL: 12.2. Restrictions on the use of JMS API in the Java EE web or
>> EJB container (a summary list for the whole API)
>> Insert new text:
>>
>> An asynchronous send is not permitted in a Java EE EJB or web container.
>> The following methods must therefore not be used in a Java EE web or EJB
>> container:
>>
>> * javax.jms.Session method send(Message message, CompletionListener
>> completionListener)
>> * javax.jms.Session method send(Message message, int deliveryMode, int
>> priority, long timeToLive, CompletionListener completionListener)
>> * javax.jms.Session method send(Destination destination, Message message,
>> CompletionListener completionListener)
>> * javax.jms.Session method send(Destination destination, Message message,
>> int deliveryMode, int priority, long timeToLive, CompletionListener
>> completionListener)
>> * javax.jms.JMSProducer method setAsync(CompletionListener
>> completionListener)
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------
>>
>> PROPOSAL: Amend the API docs for all five methods above by deleting the
>> sentence:
>>
>> Restrictions on usage in Java EE - An asynchronous send is not permitted
>> in a Java EE EJB or web container. If the application component violates
>> this restriction this method may throw a JMSRuntimeException.
>>
>> and replacing with the more explicit (and consistent with other methods):
>>
>> Restrictions on usage in Java EE - This method must not be used in a Java
>> EE EJB or web container. Doing so may cause a JMS(Runtime)Exception to be
>> thrown though this is not guaranteed.
>>
>> To make this change easier to review I've updated the draft spec and API
>> docs, which you can review in the usual place:
>>
>> http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
>> http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html
>>
>> However comments and corrections are invited and I am happy to make
>> further changes in the light of comments.
>>
>> Nigel
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>