Adam,
I agree with the CDI performance comment. CanDI starts up in seconds or
less, I believe OpenWebBeans does too.
The approach mentioned is something I've seen before. The issue I have
with it is that it abstracts too much of the JMS API away and puts too
much that should be in code into configuration (XML in this case),
potentially reducing flexibility (it's still a very cool project though
-- just probably not right as a core standard). In some ways, Spring
JmsTemplate gets it right in that regard by not abstracting too much of
JMS itself. The Resin approach is similar, but more CDI/JMS centric. As
an aside, I am not totally sold on the Seam JMS Module approach either
(again I think it reduces flexibility too much). For our design we still
kept things relatively centered around javax.jms.Message and just
focused on removing very common boilerplate code (both for send and
receive).
Cheers,
Reza
On 6/30/2011 6:05 AM, Adam Bien wrote:
> Hi Rüdiger,
> On 29.06.2011, at 17:32, Rüdiger zu Dohna wrote:
>
>> Hi all,
>>
>> most people on the EG seem to like the idea of using CDI events to bind to JMS. I like that idea, too, as I love CDI, but there may be reasons to use JMS without even that container. Namely starting the CDI context takes a noticeable amount of time, and this may be too much for some use cases.
> the startup CDI performance is only dependent on the implementation. The is nothing inherently slow in the CDI spec.
>> I also prefer to have a verb for messages, not only a message object.
>>
>> I.e. I prefer
>> createCustomer("Joe", "Doe")
>> to
>> event.fire(new CreateCustomer("Joe", "Doe"))
> O.k. but I would still allow to send messages via CDI.
>
>> This feels more natural to me. I think the only differences between a JMS and an EJB call should be that JMS is always and completely asynchronous, i.e.
>> 1) JMS methods return void and don't declare any Exceptions,
>> 2) transactions are only local,
>> 3) for the sender no business logic runs directly in the method call, and
>> 4) for the receiver no business logic runs directly outside of the method call.
> Then only an empty interface, annotated with e.g. @JMSSender would be sufficient, right? If yes, then (dynamic) proxy would implement the heavy lifting
>> For more details, please take a look at https://messageapi.java.net
>>
>> And I don't think that we should force all JMS implementations to run outside of "their" environment, e.g. in plain vanilla Java SE. If we instead would make sure that all JMS client code really runs without any modification in any JMS implementation, that would be a *big* win. If the JMS implementations specify the exact environment they need, clients would be free to choose and change their minds at any time.
>>
>>
>> Regards
>> Rüdiger
>>
>
> What do you mean by " force all JMS implementations to run outside of "their" environment"?
>
> cheers,
>
> adam
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3734 - Release Date: 06/29/11
>
>
>