Hi Adam,
On 6/30/2011 6:05 AM, Adam Bien wrote:
> On 29.06.2011, at 17:32, Rüdiger zu Dohna wrote:
>> > 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.
There has to be done quite some class loading and scanning, hasn't it?
Sure, only for the jars that contain a beans.xml, so this doesn't *have*
to be a problem, but sometimes it can. Maybe performance isn't the
reason either, maybe it's just that it's not *P*OJO any more.
>> > 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.
I love CDI, but I only like events. To me they feel somewhat foreign to
the DI concept. They look cool, but the little experience I had with
them was, that I often had to create a special message object class. A
method just seems more intuitive to me.
Maybe it's just that REST is so hip nowadays and everybody thinks of
actions as some kind of resource. Don't take me wrong: I prefer REST
over WS-* by faaaaaaaar! But I don't think that this approach is
universally suitable to everything, either.
Maybe there are good use cases for both. Maybe someone with a lot of CDI
event experience has to answer this question: How often do you create a
new message class only to a) group multiple parameters, or b) give the
parameters the semantic context of a action name? Or how often is the
message class already there and can be reused? If it's the former, I'd
say that CDI events produce boiler plate code.
> Then only an empty interface, annotated with e.g. @JMSSender would be sufficient, right? If yes, then (dynamic) proxy would implement the heavy lifting
The interface would contain at least one method. The dynamic proxy would
implement the heavy lifting of mapping the method name and the
parameters to a JMS message.
>> > 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.
>
> What do you mean by " force all JMS implementations to run outside of "their" environment"?
There was a suggestion on the list to force all JMS implementations run
in plain Java SE. I don't think that's a good thing to require from all
providers, as they now can simply rely on a lot of their infrastructure.
On 2011-06-30 10:47:07 -0400 Reza Rahman <reza_rahman_at_lycos.com> wrote:
> I agree with the CDI performance comment. CanDI starts up in seconds or less, I believe OpenWebBeans does too.
Seconds may be too slow... I can even think of a use case to use the
@Inject keyword for your own mini container that supports only a CDI
subset without events.
> 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).
I understand your point, but I don't see a practical use case to put the
logical message format into code... that's actually twice: Once on the
sender, once on the receiver. Configuring the message format is
supported only for legacy systems, normally you'd stick with the default
xml body.
And when it comes to evolving the API, I prefer explicit versioning of
statically typed APIs over dynamically adding or removing things from a
map and hoping everybody will find bugs in integration tests.
The xml configuration for the destination etc. that's currently required
by the MessageApi, could be replaced with annotations... CDI could read
them from the injection point, while it's to cumbersome to pass them
into the factory.
Have fun
Rüdiger