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
>> 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/ 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
>