users@jms-spec.java.net

[jms-spec users] Re: [jsr343-experts] Re: Re: JMS 2.0 Priorities: Proposal from Julien Dubois

From: John D. Ament <john.d.ament_at_gmail.com>
Date: Mon, 20 Jun 2011 11:37:15 -0400

Nigel,

JSR-299 did not include this capability. JSR-346 has it as a proposed
feature, as Reza noted. So no it would not work in CDI 1.0 but it would
work in CDI 1.1.

John

On Mon, Jun 20, 2011 at 11:23 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:

>
>> On 6/16/2011 8:36 AM, Adam Bien wrote:
>>
>>>
>>> On 16.06.2011, at 14:29, Julien Dubois wrote:
>>>
>>>
>>>>> 4. Using MDB everywhere
>>>>> MDBs should not be reserved for application servers. We should have
>>>>> "message-driven POJOs" as seen in Spring
>>>>> JMS, by using annotations on a simple Java object.
>>>>>
>>>>
>>>> But you will need some kind of a container. IMHO it doesn't matter
>>>> whether I'm using Spring or Weld or OSGi based
>>>> EJB container. It won't work with Java SE...
>>>>
>>>>
>>>> It can work with plain Java SE, we don't need a container for that. Last
>>>> week, I've seen a project which has done its
>>>> own implementation, which is a simple thread that polls for messages
>>>> every second. It could be turned on and off, etc...
>>>> Spring JMS does exactly the same thing (it's more advanced as you plug
>>>> in a thread pool, etc, but it's the same
>>>> idea). I've seen a lot of Spring Batch, Spring Integration, and
>>>> Tomcat-based projects use it.
>>>> A simple use case such as receiving messages should be available for
>>>> everyone, even if they just use plain Java SE.
>>>> Of course, for more complex use cases we could require Java EE.
>>>>
>>>
>>> O.k. You will need some kind of infrastructure / indirection. The thread
>>> will have to pull the messages and invoke a
>>> POJO. The POJO will be managed by something. I refer to the "something"
>>> as a container.
>>>
>>
> On 16/06/2011 17:00, Reza Rahman wrote:
> > Guys,
> >
> > I think this is somewhat an academic discussion. If the message listener
> is based on CDI @Observers (and I don't see why
> > it wouldn't be), they will be bootstrapped with CDI in Java SE when the
> CDI "container" starts. The CDI 1.1
> > specification is defining Java SE bootstrap. I think the bootstrap can
> either be declarative and/or programmatic as in
> > Weld SE.
> >
> > Cheers,
> > Reza
>
> Is there any requirement that a JSR 299-compliant CDI container is capable
> of being used in a Java SE environment? The JSR 299 spec seems a bit vague.
> (I know Weld can be, but that's a specific implementation).
>
> Nigel
>