On Thu, Aug 18, 2011 at 10:56 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> John,
>
>
> On 17/08/2011 17:37, John D. Ament wrote:
>
>> Nigel,
>>
>> Thanks and I'll actually start everyone off:
>>
>> 1. Are we all comfortable with the fact that this will not be supported
>> for the deprecated interfaces? Part of the
>> reason I listed this is that CDI has some issues with non deterministic
>> interfaces, where you have problems injecting
>> both an interface and an interface that extends that interface (both are
>> possible resolution points).
>>
>
> I think that if we adopt the proposal "(JMS_SPEC-47) Deprecate
> domain-specific APIs and propose for removal" then we most definitely should
> not add any new API which depends on them. Otherwise we won't be able to
> remove the deprecated interfaces without breaking part of the new API.
>
> So far, only you and Reza have responsed to my request for comments on
> proposing those interfaces for removal.
>
>
>
>> 2. My assumption is that CDI 1.1 will support SE.
>>
>
> We should ask them. Is anyone here on the EG? I've asked the Oracle rep.
>
I'm pretty close to most of the EG, a lot of seems to be centered around the
Weld team. It seems to be included, but not confirmed yet.
>
> This would be making part of the JMS specification dependent on provision
> of a suitable CDI 1.1 implementation. We'd need to make clear which part of
> the spec had this dependency and which did not.
>
> We'd need a suitable CDI implementation before we could run the JMS 2.0 TCK
> tests.
I'm not sure we're as much dependent vs strongly recommended here. I was
thinking about the TCK tests as well. Most of my proposal doesn't have a
strong dependence on CDI 1.1 (other than maybe using SE). The event model
implicitly requires 1.1, due to forwarding of qualifiers.
>
>
> > Do we as an expert group need to put any restrictions on behavior in
>
>> SE environments? I have not raised any restrictions, but there are
>> obvious ones:
>>
>> - What happens when there is no jndi.properties for InitialContext
>> creation?
>>
>
> The same as happens now? (a javax.naming.NamingException when you do your
> first lookup). That would seem reasonable behaviour.
>
> In Java EE, of course, the container would take care of setting JNDI
> properties for you.
>
>
> - What happens when you want to communicate with multiple providers (in a
>> bridge scenario)?
>>
>
> The MessageFactory proposal wouldn't work, I think. I mentioned that in my
> comments sent separately.
>
> Do you see any other issues?
>
> Nigel
>
>
>> Regards,
>>
>> John
>>
>>
>> On Wed, Aug 17, 2011 at 9:40 AM, Nigel Deakin <nigel.deakin_at_oracle.com<mailto:
>> nigel.deakin_at_oracle.**com <nigel.deakin_at_oracle.com>>> wrote:
>>
>> Many thanks, John, for your work in drafting these documents. I look
>> forward to reading them.
>>
>> I think sending these round as attachments is fine for now. This allows
>> the expert group, and subscribers to the
>> user alias, to read them. Please use this email thread for questions
>> and comments. I'm sure I will have some of my
>> own soon.
>>
>> I agree with John that we should seek comments as soon as possible, so
>> please respond within two weeks, after which
>> I hope we can draw some general conclusions as to what the next step
>> should be. In addition to any more detailed
>> comments, please think about the higher-level topics, such as whether
>> you agree with the general direction taken by
>> each document or whether you would prefer a different direction. Please
>> consider the implications for both SE and EE.
>>
>> I think the way John has presented this as to separate documents is
>> very helpful. To help us all manage the comments
>> that are made, I suggest we submit our comments on each document
>> separately.
>>
>> Use *this* thread ("JMS Support for DI") to discuss John's first
>> document (JMS Support for AtInject).
>>
>> I'll start another thread to discuss John's second document "JMS 2.0
>> Event Messaging".
>>
>> If you have questions about the DI/CDI technology itself, ask them in
>> either thread. I'm sure the rest of us would
>> be interested as well.
>>
>> (I appreciate I'm being a bit prescriptive about email subject lines,
>> but it really does help me ensure that every
>> comments gets considered properly, especially when I go back to old
>> threads which I intended to do shortly)
>>
>> Nigel
>>
>>
>>
>>
>>
>> On 17/08/2011 02:14, John D. Ament wrote:
>> > Hello All,
>> >
>> > Attached are documents containing my proposal for CDI support in JMS
>> 2.0. There are two documents:
>> >
>> > 1. JMS2.0AtInjectSupport - this document describes basic injection
>> capabilities that are desirable to JMS 2.0.
>> These
>> > injection capabilities allow for the injection of the standard
>> JMS client APIs into any managed object within
>> a bean
>> > archive. This document also describes some minor API changes
>> that I believe would help simplify development.
>> > 2. JMS2.0EventMessaging - this document describes a mapping process
>> from POJOs to JMS Messages, usage of the CDI
>> Event
>> > model API to send events that were observed as JMS messages to
>> specified destinations and to handle incoming JMS
>> > messages as CDI events.
>> >
>> >
>> > I started to put these up on the wiki, however the formatting
>> support in the wiki doesn't seem to be there for
>> how I was
>> > looking to structure the documents, but I'll work on getting them
>> in; I really wanted to get the documents out
>> there as
>> > I work with the wiki. I recommend reading these documents in the
>> numbered order as listed in this email. I
>> tried very
>> > hard to not make them dependent on one another, however there are
>> some shared contents between them. It makes
>> sense to
>> > support both if either is chosen for support, however there is no
>> required behavior between the documents that is no
>> > touched upon by both. I'm not sure what the process should be for
>> review, but I figure we should set a time limit on
>> > the review period, maybe 2 weeks? (Nigel, I hope you can provide
>> some feedback on a timeline, since one of the
>> issues we
>> > noted on the call was a time frame for draft). I assume all
>> comments should be posted back to the EG, If anyone
>> would
>> > like to ask me specific questions related to CDI, I assume it's fine
>> to ask directly. As a note, these should be
>> > considered in parallel to Reza's documentation on a Spring-styled
>> API.
>> >
>> >
>> > Regards,
>> >
>> > John
>>
>>
>>