It's not that the API does not need to be modernized, it just needs to
be modernized in a way that is easy for developers to use and not as
over-generalized as the current reliance on the activation config stuff
(which has way too much of an academic/ivory tower flavor). For example,
I wouldn't mind this flavor of "generic":
@Listens @JmsQueue("someQueue")
public void processMessage(Message message)
@Listens @Inbox("someInbox")
public void processMessage(Message message)
etc...
On the other hand, something like this:
@Listens @Schedule("someSchedule")
public void processMessage(Message message)
Or even this:
@Observes @Schedule("someSchedule")
public void processMessage(Message message)
Seems far more awkward/less intuitive than simply:
@Scheduled("someSchedule")
public void doSomeScheduledTask()
Keeping things generic is a fine idea, as long as we keep simple, common
things simple and complex, narrow cases doable.
As it so happens, the MDB case is actually one that is derided most
often for its over-generalized nature, which is why frameworks like
Spring avoid it in favor of domain-specific APIs (and correctly so):
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/jms.html#jms-receiving.
On 4/19/2012 10:20 PM, David Blevins wrote:
> Both JBoss and OpenEJB have Quartz based Resource Adpaters for MDBs that do get used.
>
> Not that I don't agree on many levels, which is why I'd like to see the API modernized and revitalized.
>
> -David
>
> On Apr 19, 2012, at 6:27 PM, Reza Rahman wrote:
>
>> I've yet to see a non-JMS MDB in the real world in 10+ years, so I really do question the actual value of this mode of thinking....
>>
>> On 4/19/2012 12:15 PM, Marina Vatkina wrote:
>>> Hmmm.... You all agreed to the proposed changes in http://java.net/jira/browse/EJB_SPEC-42 which will add
>>>
>>> @MessageDriven(messageDestinationLookup="jms/inboundQueue")
>>>
>>> and
>>>
>>> @MessageDriven(messageDestinationLink="ExpenseProcessingQueue")
>>>
>>> -marina
>>>
>>> Florent BENOIT wrote:
>>>> +1 for MDB not tied to JMS
>>>>
>>>>
>>>> On 04/19/2012 10:51 AM, Carlo de Wolf wrote:
>>>>> +1 on 1)
>>>>>
>>>>> I would rather not tie MDB's more to JMS.
>>>>> To me it would make more sense if we had a facility that allowed propagation of metadata into the RAR via other means.
>>>>>
>>>>> @MessageDriven
>>>>> @ConnectionFactoryJndiName("foo")
>>>>> public class MyMDB { }
>>>>>
>>>>> <message-driven>
>>>>> <jms:connection-factory-jndi-name>foo</jms:connection-factory-jndi-name>
>>>>> </message-driven>
>>>>>
>>>>> That way any type of inflow can benefit from this proposal.
>>>>>
>>>>> Carlo
>>>>>
>>>>> On 04/17/2012 12:41 AM, Marina Vatkina wrote:
>>>>>> Experts,
>>>>>>
>>>>>> JMS 2.0 EG proposed chages to MDBs described in EJB_SPEC-43. Please read (if you hadn't done so) the proposed chages and vote on the following options at the bottom of the description:
>>>>>>
>>>>>> 1) New mandatory activation property connectionFactoryJndiName
>>>>>> 2) New element<connection-factory-jndi-name> and corresponding annotation @MessageDriven(connectionFactoryJndiName=...
>>>>>> 3) Both 1) and 2)
>>>>>> 4) Neither
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1913 / Virus Database: 2411/4946 - Release Date: 04/19/12
>>>
>>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2411/4946 - Release Date: 04/19/12
>
>
>