Just to throw out some other clean-up ideas for Camel 3.0. I came across this thread here recently [1] talking about exchange patterns and the history of camel. Now that JBI is essentially dead, does it make sense to use Camel 3.0 to cleanup unused ties back to JBI? For example, get rid of the exchange patterns that Camel doesn't really support (OutIn...).
Chris [1] http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-td2836060.html On Wed, Apr 3, 2013 at 3:16 AM, Marco Westermann <marwesterm...@gmx.de>wrote: > Hi Gert, > > just commented the jira, > > regards, Marco > > Am 29.03.2013 12:05, schrieb Gert Vanthienen: > > Hey Marco, >> >> Just noticed your remark about the Exception you got when running >> things in ServiceMix and I raised JIRA >> https://issues.apache.org/**jira/browse/SMX4-1423<https://issues.apache.org/jira/browse/SMX4-1423>to >> ensure we look into >> this before doing the next release. The basic example I tried worked >> fine, but that was only exposing a web service and not calling an >> external service. If you have a moment, it would be good if you could >> add a comment to the JIRA issue explaining how we can reproduce your >> problem? >> >> Thanks in advance, >> >> Gert >> >> >> On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann <marwesterm...@gmx.de> >> wrote: >> >>> Hi, >>> >>> I use camel for more that one year now and it is actual great for >>> integration questions. One thing that I always mess around with is >>> calling >>> external web services (soap in general). And IMHO this is a central use >>> case >>> for soa / integration purposes. I received the impression that this >>> central >>> use case has not the weight it should have in an integegration framework >>> like camel. E.g. most examples with camel and cxf shows how to expose a >>> web >>> service, not how to consume one; there are maven archtypes which create >>> new >>> projects again only for exposing a service - there is no archtype for >>> consuming one. Even the camel in action book mostly covers cxf to use as >>> a >>> provider. So I think this should be made much easier with much more >>> examples. (or that easy that no example is neccessary) If you know >>> openesb >>> / glassfish esb there it is a matter of drag and drop a wsdl to the >>> project, >>> use an operation as endpoint (which you can use from a drop down box) and >>> specify the message-mapping (all is supported by easy clicky clicky) >>> >>> Don't get me wrong. I really like camel very much, but I always have some >>> problems with: >>> >>> * what component should I use (http, cxf, spring-ws) I think cxf should >>> be >>> the standard but should be easier to use >>> * most of my camel routes run in smx. my acutal problem in smx 4.5 (which >>> seems to be an osgi-problem) is that I get an exception which says that >>> no >>> org.apache.cxf.jaxws.spi.**ProviderImpl could be found. And I already >>> tried 4 >>> hours to fix this issue without success.. >>> >>> These hurdles makes it to a costly task to implement a route which should >>> call a service. IMHO this should not take longer that 5 mins to implement >>> that if you already have a wsdl for the service. >>> >>> >>> I hope my suggestions are understandable / useful. >>> >>> I which you all Happy Easter, >>> >>> regards, >>> >>> Marco Westermann >>> >>> >>> >
