Marina,
Sorry it took so long to respond to this. It's been a crazy couple of
weeks :-(.
As I mentioned previously, the basic idea is to separate asynchronous
message processing from the current MDB component model. So, in a newer
model, any Java EE managed bean (including perhaps a Servlet) could
receive a JMS asynchronous message like this:
public class SomeBean {
...
@Listens
@JmsDestination("jms/SomeQueue")
@JmsConnectionFactory("jms/ConnectionFactory")
@JmsSessionMode(AUTO_ACKNOWLEDGE)
@JmsMessageSelector("foo=bar")
public void someMethod(Message message) {
...
}
...
}
Because this would be loosely modeled after CDI/DI, the message receiver
method parameters could be quite powerful. So we could do things like this:
@Listens
public void someMethod(MyMessage message) {
@Listens
public void someMethod(String message) {
@Listens
public void someMethod(byte[] message) {
@Listens
public void someMethod(Map message) {
@Listens
public void someMethod(MyMessage message,
@JmsCorrelationId String
correlationId,
@JmsReplyTo Destination
destination,
@JmsProperty("myProperty")
int someProperty) {
@Listens
public void someMethod(Message message, @Inject SomeOtherBean otherBean) {
Because such listener methods need to be transactional, it's difficult
to go too far with this without decoupling declarative transactions from
the EJB component model. It's also the case that things like concurrency
must be figured out for this model (perhaps by decoupling @Lock from EJB
or defining @PoolScoped, @TransactionScoped or @MaxConcurrency). Besides
enabling messaging for non-EJB components, this enhancement would also
enable us to treat JMS with first-class citizen semantics and move away
from the over-generalized JCA based semantics that we have today. We
could also similarly support a JCA based model like this:
public class SomeBean {
@Listens
@ActivationConfigProperty(propertyName="mailServer",
propertyValue="mailHost"),
@ActivationConfigProperty(propertyName="mailFolder",
propertyValue="INBOX"),
@ActivationConfigProperty(propertyName="storeProtocol",
propertyValue="imap"),
@ActivationConfigProperty(propertyName="userName", propertyValue=""),
@ActivationConfigProperty(propertyName="password",
propertyValue="secret")
public void someMethod(Message message) {
...
}
}
Now, I think this is going to take quite a bit of work to standardize,
so I am not sure it is right for EJB 3.2. Also, I think we should go
down this path after the current JMS 2 discussion of a higher-level
dependency injection based API is resolved. For example, we may be able
to re-use some of the annotations being developed as part of that API.
Also, any new JMS related annotations could be defined in javax.jms
rather than javax.ejb. Similarly, I wonder if the JCA listener related
annotations really belong in javax.resource?
Note, I don't think any of this need be bound directly to CDI or CDI
events per se, although I can see us using some JSR 330 annotations and
underlying implementations using the CDI portable extension SPI (in a
relatively container specific manner).
Hope it helps. Let me know if I need to explain anything in greater
detail. I have kept this brief and high-level on purpose.
Cheers,
Reza
On 9/12/2011 6:21 PM, Marina Vatkina wrote:
> Reza,
>
> There is a plan (stay tuned) to make CMTs available outside EJBs. But
> how does it affect MDBs in the EJB container?
>
> thanks,
> -marina
>
> Reza Rahman wrote:
>> Marina,
>>
>> I think it's hard to have this discussion without starting to talk
>> about decoupling transactions (and other services) from the EJB
>> component model. Did you still want to have this discussion now?
>>
>> Cheers,
>> Reza
>>
>>
>> On 9/9/2011 9:11 PM, Marina Vatkina wrote:
>>> Experts,
>>>
>>> Does any of you have a wish-list for the MDB improvements in the EJB
>>> spec? This should be a purely EJB related changes, as the JMS 2.0 EG
>>> is looking carefully at the overall JMS revamp.
>>>
>>> thanks,
>>> -marina
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1392 / Virus Database: 1520/3886 - Release Date: 09/09/11
>>>
>>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3893 - Release Date: 09/12/11
>
>