John,
If I understand what you are saying correctly, I think we are basically
on the same page :-).
I did not like the current version of Seam JMS because it abstracted
some of the JMS APIs that really are general purpose and not just
boilerplate "stuff" (this judgment being highly subjective based on my
development experiences with JMS, Spring, Seam, etc).
If it helps, I can give you a rough outline of what we had envisioned
for Resin, but have not yet implemented or documented publicly. At this
point though, I do think we should let Nigel take the lead on things so
we can move things forward promptly.
Cheers,
Reza
On 7/7/2011 8:41 AM, John D. Ament wrote:
> I'm curious to know why you don't like the Seam JMS approach,
> personally. I would love for it to be able to support @Inject
> Event<javax.jms.Message> msgEvent; msgEvent.fire(myMessage); however
> creating messages is based on a session, and the session and message
> are dependent in some cases, however the CDI scoping requirements make
> this a little difficult to do (which one of my goals is to make that
> work right), therefore we primarily support basic object firing and no
> properties (though, I am currently working on a JmsMessage
> implementation that supported the necessary payload and properties,
> but it still requires a translation.
>
> Some more comments in line...
>
> - John
>
> On Thu, Jul 7, 2011 at 5:44 AM, Adam Bien <abien_at_adam-bien.com
> <mailto:abien_at_adam-bien.com>> 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.
>
>
> Well, when you're using CDI you already have a call back to all
> classes in the bean archive, so that lets you filter it to what you're
> going to be interested in.
>
>
>>
>>>> > 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.
>
>
> I'm curious how you're doing this, since there's currently an
> enhancement in CDI to support forwarding the qualifiers when firing an
> event, since the scoping rules are a bit unsavory (at least from my
> opinion).
>
>>
>>> 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.
>
> I'm not too sure what this means to be honest. If the issue is that a
> JMS implementation should be bootable in an SE environment, then yes I
> think that should be included. What that actually boots (e.g. a full
> web container, EJB container, CDI container, etc) will vary.
>
>>
>> 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
>