Marina,
The CDI/enablement question is actually a very interesting one. Per se,
you don't actually "need" CDI for any of this since we are just talking
about the JSR 330 annotations. The only issue is that in a Java EE
environment, currently only CDI recognizes the JSR 330 annotations,
including @Inject. That being said, binding this to CDI does have some
very good advantages:
1. The jar scanning is already figured out via META-INF/beans.xml.
2. CDI already defines integration points with all managed beans
(conceivably including Servlets).
3. CDI does the "grunt" work of component scanning, proxying, life-cycle
management, scoping, injection, etc for you.
4. Leveraging the CDI SPI can make implementations relatively portable
(I say relatively because there is bound to be requirements for deep
container integration for JCA, JTA, thread pools, monitoring, etc).
5. You could conceivably leverage the META-INF/beans.xml for XML based
configuration.
If you have a different view on this, I would certainly like to hear it.
I think the main issue of making this completely CDI agnostic is
figuring out the jar scanning. As to purely the annotations themselves,
as long as they are defined in javax.jms we could pretty much use it any
way we see fit, right (the same as injecting/managing JMS objects via
@Resource)?
You also have a very good point on the fact the
JCA/_at_ActivationConfigProperty annotations are not really JMS dependent
at all, so we can probably make pretty good progress on that independent
of JMS 2 if we wanted to. The decisions that come out of that then could
be easily reapplied to the JMS-specific case. That all being said, it
would probably be a good idea to have a discussion with the JMS 2 spec
lead about some of this just to keep him informed if nothing else...
Cheers,
Reza
On 9/26/2011 9:01 PM, Marina Vatkina wrote:
> 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
>>>
>>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1809 / Virus Database: 2085/4521 - Release Date: 09/26/11
>
>