Nigel, Graham,
Ideally, I would want to see message creation handled outside of sessions.
I would however want to verify with some implementers to make sure they feel
it is supportable.
John
On Wed, Aug 3, 2011 at 5:18 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> Graham,
>
>
> On 02/08/2011 18:56, Graham Wallis wrote:
>
>>
>>
>> Nigel,
>>
>> Thoughts inline below....
>>
>> "John D. Ament"<john.d.ament_at_gmail.com> wrote on 02/08/2011 18:10:11:
>>
>> From: "John D. Ament"<john.d.ament_at_gmail.com>
>>> To: jsr343-experts_at_jms-spec.java.**net<jsr343-experts_at_jms-spec.java.net>
>>> Date: 02/08/2011 18:10
>>> Subject: [jms-spec users] [jsr343-experts] Re: Re: JMS over CDI or
>>> something else?
>>>
>>> Hi all,
>>>
>>> I wanted to bring this back up. I am wondering if we can discuss
>>> around this particular topic? I researched into the 3 open source
>>> JMS impls I know of, and of them 2 do not support sending messages
>>> created by another session/connection. Only OpenMQ supports that.
>>> Should it be supported across the board?
>>> John
>>>
>>
>> On Mon, Jul 11, 2011 at 8:06 AM, Nigel Deakin<nigel.deakin_at_oracle.com**>
>>>
>> wrote:
>>
>>> John,
>>>
>>>
>>> On 07/07/2011 20:07, John D. Ament wrote:
>>>
>>> 1. The event model is a direct integration between serializables and
>>> sending JMS messages. Obviously, the big
>>> limitation is that a created message needs to be bound to a specific
>>> JMS session. For right now, there is no way to
>>> guarantee that the JMS SEssion used to create a message fired is
>>> then actually sent via that session, CDI doesn't have a
>>> scope that confirms that.
>>> (snip)
>>>
>>>
>> 2. The simplified APIs provided in Seam JMS are really just meant to
>>> supplement the fact that an injected
>>> MessageProducer is completely unusable as you need to guarantee that
>>> the JMS session injected for creating messages is
>>> the same one used to create your producer.
>>>
>>> I'm interested in your suggestion that you need to guarantee that
>>> the JMS session used for creating messages is the same one used to
>>> create your message producer. Where in the JMS spec or API do you
>>> think it says this?
>>>
>>
>> I think most people interpret the spec to mean that the session that owns
>> the message producer must also be used to create the message to be sent.
>> The spec doesn't actually say that per se, but I think it is implied and
>> that implication is reinforced by all the examples I've seen.
>>
>> It's also implied by articles such as
>> http://java.sun.com/developer/**technicalArticles/Networking/**messaging/<http://java.sun.com/developer/technicalArticles/Networking/messaging/>which
>> includes the following:
>> "Sessions are used to build message producers and message consumers, as
>> well as to build the messages themselves. "
>>
>>
>>> My own interpretation of the spec is that a MessageProducer must be
>>> able to send a javax.JMS.Message irrespective of how it was created.
>>> It might have been created using Session.createMessage(), or it may
>>> have been received by a MessageConsumer. It might even have been
>>> created by a foreign JMS provider (though the spec states that this
>>> might not be handled as efficiently as a provider's own
>>> implementation). Section 3.12 is worth reading.
>>>
>>> Anyone else have a view? Perhaps this is something we need to
>>> clarify, if it would make building frameworks easier.
>>>
>>
>> You are correct that a MessageProducer might be sending a message received
>> by a MessageConsumer, as opposed to created locally, but for locally
>> created messages I think most people believe (rightly or not) that there
>> is
>> a requirement for session affinity.
>>
>
> Sounds like we have yet another area in the spec which is unclear.
>
> For those vendors which require a message to be sent using the session that
> created it, is this restriction simply added as a check, to comply with a
> perceived spec requirement, or do these vendors' implementation depend on
> it?
>
> I can see a benefit in separating the factory methods for creating messages
> from the Session object, as part of our API simplification initiative. Do EG
> members have a view on whether this would be desirable, and, if so, how
> difficult it would be to implement such a change?
>
> The existing need to support Message objects implemented by a foreign
> provider implies that a MessageProducer can already treat a message as being
> an opaque object which only implements the javax.jms.Message interface,
> which suggests to me that it wouldn't be too difficult.
>
> Nigel
>
>
>
>
>> In fact, thinking about this further brings up another question, which is
>> why an application has to be connected to a messaging provider in order to
>> create a message. We obviously need the provider to supply a concrete (and
>> provider-specific) implementation of the Message interface, but the act of
>> creating a connection (and a session) involves far more than would seem to
>> be necessary to create a message object.
>>
>>
>>> Nigel
>>>
>>
>>