Hi Rüdiger,
On 04.07.2011, at 18:42, Ruediger zu Dohna wrote:
> 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.
Whether it has to scan, or not, I really do not care when it is fast enough :-) I don't think it is an issue.
What is actually the definition of POJO? No proxies allowed between or no bytecode extension?
I would like to see a strong integration of all Java EE 7 specs and pruning all overlaps.
>
>>> > 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.
Why not a Qualifier?
> 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.
In all my cases all event classes in CDI are just my domain classes. I use Qualifiers as replacement for topic names.
>
>> Then only an empty interface, annotated with e.g. @JMSSender would be sufficient, right? If yes, then (dynamic) proxy would implement the heavy lifting
One of the first feature requests in CDI 1.1 (Java EE 7) is the support for interception of Abstract classes / interfaces:
https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589523#comment-12589523
This would also solve this issue in a standard way.
>
> 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.
Or an interceptor / ServiceHandler. Why to re-invent the wheel?
>
>>> > 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.
+1.
>
> 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.
So far the performance of CDI (Weld in particular) was far better than expected....
>
>> 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
>
> <ruediger_dohna.vcf>