Adam,
Thanks for posting this. I agree with you 100%.
Cheers,
Reza
On 7/7/2011 5:44 AM, Adam Bien wrote:
> 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
> <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
>> <mailto: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>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1388 / Virus Database: 1516/3748 - Release Date: 07/06/11
>