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