Reza,
Thank you for the description. Will these new JMS annotations be
available without CDI being enabled?
Do you propose @ActivationConfigProperty support on a managed bean
method to be coupled with the upcoming JMS changes, or orthogonal to
them? Which part do you expect to take time to standardize?
thanks,
-marina
Reza Rahman wrote:
> 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
>>
>>
>