James Innovation Inc. Strikes again !!! I love you example. Programming against interfaces and still having all the EIP, routing and ESB stuff doing the work. That is truly hiding the middleware.
Now if only the annotations was a javax.xxx standard ;) But then again we must wait XXX years for anything innovative to happen and then James will be miles ahead. So we stay with org.apache ;) +1 to @deprecated the MessageDriven but sadly its also a good name for "classic developers" that has been stuck in EJB land to long. MessageDriven is a MDB and interface they know. The consume/produce names is new words for them. But hey the world is moving and you need to catch up sometimes. So get Hopes book and start reading! I was wondering if @Consumer and @Producer are better names than @Consume, @Produce. Just as a non English reader for the first time would have though they were named ending with ...r. Well that is what you read all the time in Hopes book - consume_r_ and produce_r_ The last part about mixing with spring remoting Export/Proxy. Well my initial thought is to separate it, but I think we need more time to experiment and see what feels most natural and best. And we can consider Camel 1.5 the first shot and then we have community feedback from early adapters and we have time to adjust it in Camel 2.0. I think its important that the annotations approach cater for both simple usages and the more advanced. The sample now is simple and possible to explain and introduce to a bunch of "classic developers". Beware this is written without my first cup of coffee really kicking in!!! Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: 12. august 2008 19:42 To: [email protected] Subject: thoughts new naming convention & new annotation for producer / consumer in POJO mode Right now we can mark a method as @MessageDriven in the bean integration... http://activemq.apache.org/camel/bean-integration.html public class Foo { @MessageDriven(uri="activemq:cheese") public void onCheese(String name) { ... } } we can also mark methods has having a message exchange pattern (i.e. to mark methods as being InOnly - for one ways as apposed to request/reply). http://cwiki.apache.org/CAMEL/using-exchange-pattern-annotations.html so having the produce side would make sense to avoid coupling the POJO to camel interfaces to help hide all the middleware APIs.... http://activemq.apache.org/camel/hiding-middleware.html There's a JIRA for this... https://issues.apache.org/activemq/browse/CAMEL-816 I've just checked in a first spike at a first implementation of this... http://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-spring/src/test/java/org/apache/camel/spring/produce/ There's the producer interface, MyListener, an implementation and a test case that has the producer injected using @Produce which also binds it to an endpoint - then the implementation of the interface binds it to an endpoint. Under the covers this is using the same infrastructure as the spring remoting really. So after this long ramble am wondering... * should we rename @MessageDriven to @Consume (keeping it around until 2.0 and deprecating @MessageDriven for now)? * is @Produce a good name of an annotation; in some ways is more like @Proxy - as it can do both a one-way send or a request/reply? * if we supported @Consume on a class level rather than just a method level like @MessageDriven; should we call it @Export (like the spring remoting proxy and export sides) rather than Produce and Consume * so maybe we should separate the remoting stuff from the send message / consume message stuff? So support @Proxy / @Export for spring remoting style stuff; and a separate method level @Produce (where the payload is just the parameter value(s)) and @Consume on a method level? i.e. in spring remoting the payload is a BeanInvocation bean which contains the the arguments and the MethodBean (details of the type, the parameter types and method name etc). Sometimes we just wanna send - say a JMS TextMessage so we might wanna miss that stuff out and just send the single parameter value of a method as the payload There's a number of ways of slicing and dicing this - just thought I'd start a little bit of brainstorming -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
