Reza,
Reza Rahman wrote:
> 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.
But you won't put JMS info there, right? In particular with the Platform
EG discussion on standardized resources definition...
>
> 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.
All pre-CDI containers know how to scan Java EE applications. So
scanning shouldn't be the reason to use CDI.
> 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...
Nigel is reading all our discussions on the users copy.
Best,
-marina
>
> 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
>>
>>
>