Nigel,
Just wondering, did you happen to catch Paul Bakker's talk about CDI at the
start of Devoxx?
John
On Mon, Nov 14, 2011 at 5:50 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> (For all those who have got lost following these discussions: I'll write
> this up properly within the next week or so and we can discuss it properly.
> (When I do so it will still be a tentative suggestion rather than a
> definite proposal).)
>
> Below...
>
>
> On 11/11/2011 20:39, Rüdiger zu Dohna wrote:
>
> Nigel,
>
> I like your proposal to merge Session and MessageProducer into a
> MessagingContext. And in an EE setting, it would be trivial to inject that.
>
> In your proposal it's not perfectly clear that also in the SE setting,
> it should be possible to abbreviate
> connectionFactory.createConnection().createMessagingContext() as
> connectionFactory.createMessagingContext(), right?
>
>
> I don't think so. In SE the application would need to be able to control
> whether they want two messaging contexts (i.e. sessions) to use the same
> underlying connection or not. That's why we would need to introduce an
> additional object that represents the connection in the SE case, which
> isn't needed in the EE case.
>
> Nigel
>
>
>
>
> On 11.11.2011, at 18:41, Nigel Deakin wrote:
>
> On 11/11/2011 17:04, Clebert Suconic wrote:
>
>
>
> On Fri, Nov 11, 2011 at 10:59 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
>
>> On 11/11/2011 16:08, Clebert Suconic wrote:
>>
>>> I'm not sure I like this next proposal... so, another brain storm...
>>>
>> which one don't you like?
>
>
> This one I"m making now...
>
>
>
>>
>>
>>
>>> What if we had 4 basic objects?
>>>
>>> NewConnectionFactory
>>> NewConsumer.... created with cf.createConsumer(queue);
>>> NewProducer .... created with cf.createConsumer(queue);
>>> NewRequestResponse... created with cf.createRequestResponse(queueSend,
>>> queueConsume); That would be a Consumer/Producer mixed in a single object
>>> for the case of the request/response.
>>>
>>>
>> Can you explain what you mean by "request/response" here? Are you
>> describing the requestor application or the responder application? Are you
>> thinking of EE or SE?
>>
>>
>
> I'm thinking of any use case where Consumer and Producer need to be in
> the same Context.
>
>
> Ah yes. That would be the responder part of request/response. I agree it's
> a common use case, but I think we should be aiming at a API which is really
> simple and doesn't need special API to support such important cases.
>
>
> I'm thinking of SE. For EE we can just rely on XA.
>
>
>
> As I mentioned, if we want to avoid two-phase commit when using separate
> sessions the JMS provider needs to support joining of resources, which is
> not currently mandatory
>
> -----
>
> I still like my own proposal for:
>
> a. Merging Session and Connection (easy for Java EE, a major restriction
> for Java SE)
> b. Removing the need to create a MessageProducer for anything
> c. Removing the need to create a MessageConsumer when using a
> MessageListener (Java SE only)
>
> Which leaves us with the following main interfaces:
>
> 1. ConnectionFactory
>
> 2. NewConnection (perhaps MessagingContext is a better name) - This is a
> merged connection, session and anonymous producer, which also supports
> setMessageListener() where allowed.
>
> 3. SyncConsumer
>
> I think that's pretty simple.
>
> Perhaps we can address the Java SE case by formalising two separate ways
> to create MessagingContext objects, one for EE and one for SE:
>
> In EE you call connectionFactory.createContext() to create a
> MessagingContext.
>
> In SE you call connectionFactory.createConnection() as at present, and
> then call Connection.createMessagingContext() to create one or more
> MessagingContext objects which use the same underlying connection. The rest
> of the API would be the same.
>
> I think I'll write this all up over the next week or so. If you'd like to
> write up your own ideas in a bit more detail please do. I think it'll be
> easier for us to review each other's ideas then.
>
> Have a good weekend.
>
> Nigel
>
>
>>
>>> Anything different than that would have to go through JTA. (Merge on JTA
>>> would take care of placing everything as part of the same TX)
>>>
>>>
>>> No more need for Contexts on that case.
>>>
>>
>> As I wrote earlier, I don't think we should assume that the RM
>> implements isSameRM() to return true.
>>
>>
>>
>>>
>>> Just a brain storm..I'm not 100% sure about if I like it or not.
>>>
>>
>> I don't think we're there yet.
>>
>> I still like my own proposal from yesterday. Can you take a look and let
>> me know what you think? Would you like me to explain it better?
>>
>> Nigel
>>
>
>
>