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