John,
* I think this is where we may be running into a problem. CDI isn't
providing the JMS support, JMS has to provide either CDI support or
AtInject support or both. I don't know that there is much use in
- I think I answered this in my previous email. The basic point here is
that I think we can simply stick to JSR 330 annotations/concepts even if
the actual specification text/TCK/reference implementation is CDI based.
It makes it possible to create functionality that looks very similar to
this in non-Java EE environments without having to actually use CDI.
Alternatively, it is indeed possible to avoid JSR 330 and CDI altogether
in favor of JMS specific injection/resource management annotations.
* This is one case where injection needs to be done by the JMS
implementation, not just a CDI wrapper, since messages can only be
created by the implementation.
- I'm afraid I'm still not quite sure what you mean? Maybe we are just
miscommunicating here. Here is what I am thinking (taken directly from
my initial detailed proposal):
@Inject @JmsConnectionFactory("jms/MyConnectionFactory") TextMessage
message; // Transaction-aware proxy.
@Inject @JmsDestination("jms/MyQueue") MessageProducer producer; //
Transaction-aware proxy.
@Transactional
private void send(String messageText) {
message.setText(messageText); // Message created from underlying
session. The actual message is a delegate of the proxy.
producer.send(message); // Producer created from underlying session.
The actual producer is a delegate of the proxy. The producer proxy
detects that it is dealing with a
// message proxy and
unwraps the actual message instance. It passes it to the actual producer
instance.
}
What is the issue here? Is there a problem specific to the current Seam
JMS implementation?
* There should only be one way to provide the literal anyways, so why
not give it out of the box?
- The issue I see is that it introduces a specific API dependency on CDI
and it introduces a new API in addition to plain JMS that I'm not sure
has tangible value.
* What about when there's no container (e.g. SE)?
- In view of the fact that SE support is really more a "nice-to-have"
rather than a "must-have" in this case and this API duplicates what is
already available in a Java EE environment, I think we should defer this
until the JMS abstraction in Java EE environments is fully figured out,
which is the focus of the current effort.
Hope this makes sense.
Cheers,
Reza
On 8/30/2011 8:10 PM, John D. Ament wrote:
>
>
> On Tue, Aug 30, 2011 at 7:32 PM, Reza Rahman <reza_rahman_at_lycos.com
> <mailto:reza_rahman_at_lycos.com>> wrote:
>
> John,
>
> * Unfortunately, I don't think there's much we can provide if it's
> only JSR-330. Would we then require JMS implementations to
> support the Provider interface for all injectable interfaces?
> - As I mentioned, we can say that in a Java EE environment, CDI
> will provide the injection services and code the actual TCK that
> way. It's more of a question of keeping a focus on trying to stay
> limited to JSR 330 so that Spring/Guice/non-CDI JMS 2
> implementations in Java SE can provide the features easily.
>
>
> I think this is where we may be running into a problem. CDI isn't
> providing the JMS support, JMS has to provide either CDI support or
> AtInject support or both. I don't know that there is much use in
>
>
>
> * I don't know if it will work well in a multiple implementation
> environment.
> - Can you please elaborate? What specific concerns did you have in
> mind beyond the message/session binding ambiguity?
>
>
> This is one case where injection needs to be done by the JMS
> implementation, not just a CDI wrapper, since messages can only be
> created by the implementation.
>
>
> * One issue I know the seam guys ran into was that no literals
> were provided out of the box.
> - What was the specifics of the issue? Was it implementation
> related or JMS related?
>
>
> Just a lot of extra boilerplate code that may have not been necessary
> if it was provided for. There should only be one way to provide the
> literal anyways, so why not give it out of the box? It should just be
> API.
>
>
> * It's one example, we could require a CDI extension that injects
> as well.
> - I'm not sure I understand. Can you kindly elaborate? Why
> wouldn't JCA pluggability at the container level be enough?
>
>
> What about when there's no container (e.g. SE)? JCA plugability isn't
> defined within CDI so the only trigger would be the presence of an
> extension.
>
>
> * This goes back to the other side of my proposal. They won't
> need to be here, however for events to work they need to be
> - That's what I figured. I think if that part of the proposal does
> not have much support this time around, we could remove this for now.
>
>
> Potentially.
>
>
> * I'm not against using a standardized scope, but this sounds like
> something that we need to get clarified at the platform level or
> within CDI.
> - As I mentioned, I don't think we actually need a standardized
> scope for this at all. The actual transaction scope really is an
> implementation detail in this case (as is CDI per se). In fact,
> you could implement it the same way the JPA transactional context
> is implemented today, even with Spring.
>
> Cheers,
> Reza
>
>
>
> On 8/30/2011 7:02 PM, John D. Ament wrote:
>> Reza,
>>
>> I have some comments inline.
>>
>> On Tue, Aug 30, 2011 at 4:58 PM, Reza Rahman
>> <reza_rahman_at_lycos.com <mailto:reza_rahman_at_lycos.com>> wrote:
>>
>> 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).
>>
>>
>> Unfortunately, I don't think there's much we can provide if it's
>> only JSR-330. Would we then require JMS implementations to
>> support the Provider interface for all injectable interfaces?
>>
>>
>> * 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.
>>
>>
>> This relates back to a note that Nigel had passed around. the
>> existing methods would need not be modified, but new methods
>> could potentially use the enum. Plus, in this case we can make
>> more type safe. Perhaps the enums would have int values and the
>> necessary translation capabilities.
>>
>>
>> * @JmsCredentials is not really very appropriate in a Java EE
>> environment where such configuration would likely be
>> specified at the container/resource level.
>>
>>
>> Agreed, would only be useful in SE.
>>
>> * 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.
>>
>>
>> So I was thinking about this a bit more through the hurricane. I
>> decided that the method belongs best at the ConnectionFactory
>> level. I thought about injecting messages as you had said when
>> we met up, I don't know if it will work well in a multiple
>> implementation environment.
>>
>> * 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.
>>
>>
>> One issue I know the seam guys ran into was that no literals were
>> provided out of the box. From my perspective, I think the
>> literals should be provided just to make it one last thing that
>> doesn't need to be boilerplate code.
>>
>> * 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.
>>
>>
>> It's one example, we could require a CDI extension that injects
>> as well. Don't know if we even want to provide concrete classes
>> in the api at all at this point, but I think it would make some
>> things a bit easier.
>>
>>
>> * 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?
>>
>>
>> This goes back to the other side of my proposal. They won't need
>> to be here, however for events to work they need to be.
>>
>>
>> * 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.
>>
>>
>> I'm not against using a standardized scope, but this sounds like
>> something that we need to get clarified at the platform level or
>> within CDI.
>>
>>
>> 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 <http://www.avg.com>
>> Version: 10.0.1392 / Virus Database: 1520/3835 - Release
>> Date: 08/15/11
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 10.0.1392 / Virus Database: 1520/3867 - Release Date:
>> 08/30/11
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3868 - Release Date: 08/30/11
>