This has been mentioned a few times, but no agreement was reached.
Actually we should drop the whole MEP as it makes little to no sense. It
could be a hint at best. For me the rationale has little to do with JBI.
The MEP only makes sense for an Endpoint (i.e. Producer or Consumer) but
not for the Route. We might want to keep it as a header for edge cases
like content (header) based routing, although there are a few other ways
to solve that.
My $0.02,
Hadrian
On 04/03/2013 02:58 PM, Chris Geer wrote:
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
