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