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> 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
>
> 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> 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>
>
>
>
>