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