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