I haven't checked the spec recently, but the TCK has zero MDBs.
-David
On Dec 13, 2011, at 3:53 PM, Reza Rahman wrote:
> I think CDI already does that?
>
> On 12/9/2011 11:12 AM, David Blevins wrote:
>> My vote would also be for both. There's a proposal here that I've been wanting to make, will do that in another mail.
>>
>> No one in the thread mention the obvious one that MDBs should be allowed to have CDI injection like session beans. We added it in our impl though it's definitely not part of the spec or TCK.
>>
>>
>> -David
>>
>> On Nov 2, 2011, at 2:18 AM, Adam Bien wrote:
>>
>>> Reza,
>>>
>>> I would offer both - an Interface to implement (like MessageDrivenBean) and an annotation.
>>>
>>> I personally prefer the @Listens annotation...
>>>
>>> cheers!
>>> On 29.09.2011, at 03:27, Reza Rahman wrote:
>>>
>>>> Marina,
>>>>
>>>> Responses inline:
>>>>
>>>> On 9/27/2011 11:48 PM, Marina Vatkina wrote:
>>>>>> Since any sensible managed bean method could potentially be an asynchronous message receiver via @Listens, you could indeed have more than one "onMessage" methods for a bean. I think this enhances flexibility and usability in important ways for developers.
>>>>>>
>>>>>> Honestly, I wasn't thinking much about the current EJB component model at all, but I don't see why SLSBs and Singletons could not have @Listens methods too (the SFSB case would be trickier). The real goal in my mind is really to unlock the messaging services from a special purpose component so that they are more generally available/usable across all Java EE components. As a side-effect, we would discourage further use of @MessageDriven and conceivably deprecate it one day.
>>>>> May be yes, may be not... Having a dedicated bean for message consumption can be useful with bean/thread pooling setup...
>>>> We actually discussed this issue as well as thread-safety in great detail internally at Caucho. The conclusion we reached is that there really isn't a concrete need to actually pool bean instances themselves. What is really needed is a pool/queue of listeners forwarding concurrent messages to the bean instance. You can achieve this using something like @MaxConcurrency at the listener level. Thread safety issues can be resolved by making Java EE resources transaction scoped and providing @TransactionScoped for third-party integrations (incidentally this is basically what Spring does for messaging). Alternatively, you could also either use @Lock or @PoolScoped. In effect, what we would be doing is deconstructing the EJB services to their basic parts and letting the user compose them the way it best suits them as opposed to having a "magic" set of services added via @MessageDriven. I think the fact that the services are so tightly bound together in a component model is what makes it difficult for developers to grasp - especially because the component model suddenly becomes so far removed from a normal Java object.
>>>>
>>>>>> Now, strictly speaking, you could remove the need to have @Listens and simply process messages if we see @JmsDestination, @ActivationConfigProperty, etc but I think it would be an actual net reduction in readability (kind of the same thing as omitting the @Inject annotation in the early versions of CDI).
>>>>> I'm not sure @Listens adds readability, but I'd be interested in what others think...
>>>> I'm actually very interested in hearing a few other opinions as well :-). Besides adding readability, @Listens also gracefully handles the case of listening to the default queue:
>>>>
>>>> @Listens
>>>> public void handleDefaultQueueMessages (Message message)
>>>>
>>>>>> If you are asking why we could not literally have multiple "onMessage" methods, the issue of course is that Java will not allow you to have more than one method with the same signature (I very much doubt that's what you are asking me, but I'm just making sure).
>>>>> I just meant the method with "onMessage" functionality, like a timeout method. If we go this route, we'd need to come up with a good name for those methods.
>>>> Personally, I'm not a big fan of the archaic onMessage/timeout style default names that we've inherited from EJB 2.x style heavy weight component models. That being said, "onMessage" seems like a good enough name and it would retain some sense of backwards compatibility.
>>>>
>>>> Cheers,
>>>> Reza
>>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1873 / Virus Database: 2102/4674 - Release Date: 12/11/11
>>
>>
>>
>
>