users@jms-spec.java.net

[jms-spec users] [jsr343-experts] Re: Re: Re: JMS Support for DI

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Fri, 25 Nov 2011 17:41:03 +0000

John,

Thank you for the ideas.

What is the purpose of MessageBuilder, TopicBuilder or QueueBuilder objects? Are these standard interfaces implemented
by the JMS provider? What methods would they have?

What's a "plan object"?

Can you give a few examples of what the application code would look like?

Nigel

On 24/11/2011 00:06, John D. Ament wrote:
> All,
>
> I wanted to propose a possible solution to this issue. I had previously not wanted to propose it since I wanted to
> avoid new APIs to solve the issue. Its clear though that we need to have a new API to manage CDI capabilities. I
> want to respond specifically to Nigel's comments from Devoxx separately, so that will come shortly.
>
> The idea is to provide a simple builder API for working with messages, both sending and receiving. I've thrown around
> in my head a few ideas, such as MessageBuilder, TopicBuilder or QueueBuilder. I would break the interface into sets
> of methods:
>
> 1. Set of methods responsible for configuring the builder.
> 2. Set of methods responsible for creating messages from the builder.
> 3. Set of methods responsible for sending messages and plan objects (not necessarily POJOs?) to destinations.
>
> For the first part, we would introduce methods for setting the connection factory, transactionality and acknowledge
> mode. I would not include destinations here, since I would like to be able to connect to multiple destinations.
>
> For the second group, I would create overloaded methods javax.jms.Message newMessage(X param) where X could be one of
> Serializable, String, Map<T,R>, byte[], char[], Stream, etc. The returned type would be the correctly typed method.
>
> For the third group, I would add similar methods for sendXMessage(X param), mostly for readability. These would match
> up to each of the message types. In addition, we would support a send that takes a Message object.
>
> So here's how all of this correlates with CDI..
>
> You should be able to inject this builder object (or perhaps a builder factory) to your application. The injection
> should always be a blank slate. In addition, you should be able to leverage reusability of code to make your own
> customer builder. Let's suppose the following injection point...
>
> @Inject MessageBuilder builder;
>
> Then let's say you want to map the qualifier @EnterpriseSystem to have the connection factory found at jms/Enterprise
> and set transacted to true, you should be able to handle that with CDI:
>
> @Inject MessageBuilder builder;
>
> @Resource(mappedName="jms/Enterprise")
> private ConnectionFactory cf;
>
> @Produces
> @EnterpriseSystem
> public MessageBuilder createEnterpriseBuilder() {
> return builder.connectionFactory(cf).transacted();
> }
>
> So that when you did
>
> @Inject @EnterpriseSystem MessageBuilder builder;
>
>
> So basically, JMS would expose an interface (or maybe more than one?) that handled injectable components. They would
> not be bound to a connection factory at the creation level, but instead be configured by the application developer.
> We allow for DRY support but put the ownership on the application developer.
>
> I hope this is clear enough for everyone, though I'd love for feedback.
>
> John
>
>
> On Wed, Nov 23, 2011 at 7:37 AM, Pete Muir <pmuir_at_bleepbleep.org.uk <mailto:pmuir_at_bleepbleep.org.uk>> wrote:
>
> I spent some time looking at the DI problem that Nigel, Reza and Siva kindly explained to me at JavaOne. I can't
> find a good way to support DI cleanly with the current object structure in JMS.
>
> Having spent a long time looking at DI, I would also highlight that using DI to fix an API is normally likely to
> fail. It's a much better idea to fix the underlying API to accurately reflect the use cases that people are
> commonly trying to solve, whilst still not making those other use cases impossible!
>
> So I would just like to fully support Clebert's approach here!
>
> On 22 Oct 2011, at 01:54, Clebert Suconic wrote:
>
> > Maybe that's a crazy idea. What if we took a totally new approach?
> > Why do we still need connections sessions consumers and producers?
> >
> > What if we only had producers and consumers?
> >
> > You could maybe have producer extending AbstractSession and have commit, rollback... Etc
> >
> > The issue with annotations would be gone if we take an approach like that.
> >
> >
> > Consider this a brain storm please. Don't flame me if that's a crazy idea. Especially that I'm writing this in a
> Friday through the iPhone while drinking some wine :)
> >
> > Have a nice weekend.
> > Sent from my iPhone
> >
> > On Oct 21, 2011, at 7:39 PM, Reza Rahman <reza_rahman_at_lycos.com <mailto:reza_rahman_at_lycos.com>> wrote:
> >
> >> It's a point I made before. If we leave things be on this for JMS 2, it gives projects/products like Seam 3 JMS
> and Resin room to evolve further to bring about proven/mature solutions that real-world customers use successfully
> in significant numbers. Currently, Seam 3 JMS is still in beta and Resin has a design and no implementation yet. I
> think that's the real underlying problem we have rather than any fundamental usability issue with what we need to do.
> >>
> >>
> >> On 10/21/2011 7:48 AM, Nigel Deakin wrote:
> >>> On 21/10/2011 03:12, Reza Rahman wrote:
> >>>> Not to put too negative of a spin on this, but I don't think it would be terrible for non-standard solutions
> in this problem space to evolve a bit more.
> >>>
> >>> There are rather too many negatives in that sentence for me to understand what you mean. Can you say a bit more?
> >>>
> >>> Nigel
> >>>
> >>>>
> >>>> That being said, we should still give this an honest try I think...
> >>>>
> >>>> On 10/19/2011 7:24 AM, Nigel Deakin wrote:
> >>>>> Dear All,
> >>>>>
> >>>>> It's time for an update on progress on proposals to allow the injection of JMS objects into Java EE and Java
> SE applications.
> >>>>>
> >>>>> The last update you had from me on his subject was on 7th September, when I circulated minutes from a call I
> had with EG members Reza (Rahman) and John (Ament) to discuss John's AtInject proposals which were circulated earlier.
> >>>>>
> >>>>> Since then Reza, John and I have had one or two further calls and extensive email correspondence. I wrote a
> new document, based on the ideas in John's, which attempted to define a set of annotations which could be used to
> inject JMS objects into applications. An updated version of this document is attached to this message. It lists a
> fairly complete set of possible annotations to inject almost all JMS objects, but it leaves a number of important
> issues unresolved, and until we can resolve these issues this document is simply a statement of desire rather than
> a realistic practical proposal.
> >>>>>
> >>>>> The unresolved issues are listed in the document, but in summary, the main ones are
> >>>>> * The relationship between injected objects
> >>>>> * Avoiding repetition on annotations
> >>>>> * Injected objects cannot be local variables
> >>>>> * Scope of injected variables
> >>>>> * Java SE support
> >>>>>
> >>>>> It is important to appreciate that if we can't resolve these issues then we will probably need to abandon
> the document and start again.
> >>>>>
> >>>>> When I was at JavaOne earlier this month Reza and I had a meeting with Pete Muir, spec lead for CDI
> (Contexts and Dependency Injection). He offered to work with us to see whether it would be possible to achieve
> what we wanted in a reasonably standard manner using CDI - either the existing version or a future version.
> >>>>>
> >>>>> Since it's been a few weeks since I gave the full expert group (and user list) an update on this, please do
> feel free to ask questions about the attached document, make comments, or raise issues. Also, if you think you
> have ideas on how to resolve the unresolved issues please say so!
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Nigel
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----
> >>>>> No virus found in this message.
> >>>>> Checked by AVG -
> >>>>> www.avg.com <http://www.avg.com>
> >>>>>
> >>>>> Version: 2012.0.1831 / Virus Database: 2092/4562 - Release Date: 10/19/11
> >>>>>
> >>>>
> >>> No virus found in this message.
> >>> Checked by AVG - www.avg.com <http://www.avg.com>
> >>> Version: 2012.0.1831 / Virus Database: 2092/4565 - Release Date: 10/21/11
> >>>
> >>
>
>