John,
Overall, I think the @Inject support for JMS 2 proposal is a good start.
The way I see it, we should focus on getting this right before spending
too much time considering the other approaches since it is the least
intrusive and most flexible.
Specific concerns below that we could discuss further (tried hard to be
as concise as possible - please ask follow-up questions):
* I think we should avoid making this CDI specific as much as possible.
I think all of this can really be done by just sticking to the
javax.inject APIs and concepts. We could add a comment in the spec that
these features would be implemented using CDI in a Java EE environment.
In terms of the TCK, it might be necessary to use META-INF/beans.xml to
trigger injection. It would have been nice to just be able to use
@Resource for this, but the issue is that @Resource does not have much
flexibility in terms of adding the additional meta-data that would be
needed for this (it is also not that readable as compared to the more
general purpose @Inject and might be treated as "legacy" in most Java EE
6 applications). The big benefit to sticking to JSR 330 is that non-CDI
containers like Spring and Guice could still implement this API as could
some JMS providers that would support these features in Java SE (in
non-standard ways) and still not require a CDI container. It is also the
case that Spring already supports concepts like the transaction scope
that could be leveraged to make this approach scalable in a server-side
environment (more on that below).
* I'd rather not add the AcknowledgeMode enumeration. If the JMS API
were designed today, this is the route we'd likely go, but adding this
now introduces a potentially confusing redundancy that really does not
provide much practical value right now.
* @JmsCredentials is not really very appropriate in a Java EE
environment where such configuration would likely be specified at the
container/resource level.
* I don't think MessageFactory is needed at all if we simply allow for
injecting proxied, transaction-scoped message sub-types and enhancing
message producers/consumers to directly handle Objects (in fact, a major
goal of DI is to avoid such factories/resource look-ups). I detailed
such a mechanism in my initial write-up of this approach. I do know Seam
JMS does not support this today in part due to the session/message
coupling ambiguity but we could simply get that ambiguity cleared up for
JMS 2 instead of introducing a potentially redundant API.
* I don't think JmsDestinationLiteral, JmsConnectionLiteral or
JmsCredentialsLiteral are needed at all. Where additional programmatic
flexibility is needed, it is sufficient to simply inject and/or look-up
higher level JMS objects/resources like connection factories,
destinations, connections and sessions. The look-ups would be performed
via JNDI just as they are done today. Introducing these also creates a
CDI dependency that can be avoided.
* ConnectionProducer seems to be a CDI specific implementation detail
that can be avoided in favor of JCA pluggability and existing Java EE
container defaults. I think this not really needed.
* The implicit conversion is definitely a good idea the way I see it. I
think it should be supported for both sending and receiving messages. I
did mention this in my JMS utility API proposal too.
* I think all usable non-deprecated JMS objects including messages,
temporary queues/topics and connection meta-data should be injectable,
not just connections, sessions, message producers, message consumers and
queue browsers. This would be pretty easy to implement and add to
usability. Now, I do understand that this is not what is currently in
Seam JMS. Is the difficulty here the reliance on CDI producers as
opposed to creating custom proxies or is this just a simple oversight?
* I don't think @JmsConnection, @JmsDestination, etc need be qualifiers.
They can simply be plain annotations. Making them qualifiers adds a
needless dependency and I can't think of a case where it is actually
necessary to use these annotations as qualifiers?
* The issue of correct scoping for the injected JMS objects is pretty
critical to guaranteeing scalability across different container
implementations/applications/environments. I do know that Seam JMS
currently has these injected objects in the dependent scope, in part
because there is not yet a standard @TransactionScoped for CDI as of
yet. The problem is that having these objects in the dependent scope
will eventually cause the connection pool to run out if the objects are
injected into very long-lived objects such as Servlets, pooled stateless
session beans, singletons and application scoped services. This is
basically the opposite problem of the connection thrashing that happens
with Spring JmsTemplate. JPA avoids this problem by making the
persistence context transaction scoped by default and caching underlying
logical sessions/connections per transaction (and limiting the extended
persistence scope option to stateful session beans). We can specify the
same thing for injected JMS objects in addition to specifying
inter-dependencies for intermediate JMS objects to maximize resource
re-use. For reference, I outlined the solution that we had for Resin in
my initial detailed proposal. Now, implementing transaction scoped
resources does typically require some vendor-specific code to interact
with the underlying transaction manager. This can be modularized very
easily just as is done for EclipseLink as well as JBoss/Hibernate (I am
sure the folks responsible for that code base could easily help us if
needed). We also have a @TransactionScoped annotation implemented in
Resin that might help here. As such, this could be specified without
explicitly specifying CDI either and just sticking to JSR 330.
Hope this makes sense. Is it a good idea to have another conference call
to sort some of this out? Alternatively or in addition to, I am happy to
meet in person again as well.
Cheers,
Reza
On 8/17/2011 9:40 AM, Nigel Deakin 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3835 - Release Date: 08/15/11
>
>