I really don't think so. The CXF component have unique and important
features that simply cannot be replaced by other components in camel-cxf.
Camel transport is a CXF transport that can be plugged into CXF stack.
It is a building block for other components (e.g. cxfbean) and other use
case, but it does not replace CXF component all at
Cxfbean uses Camel transport to host JAXWS/JAXRS POJO and that's it.
The message received cannot be routed to another Camel component and
cannot be used to invoke an external REST/SOAP service.
Cxfrs is the REST's counterpart of cxf. It is quite verbose. By your
logic, we should remove it as well.
As you can see, cxf fills a huge hole in terms of features.
CXF component features:
- consumer (server) to listen for SOAP requests and turn requests into
either POJO, XML parts, or RAW HTTP message. The message is then routed
to other Camel component.
- producer (client) to invoke an external SOAP with given message
(again, it can be POJO, XML parts, or RAW HTTP).
CXF component follows the standard Camel pattern (Consumer/Producer etc)
nicely. The setting up CXF endpoint is pain in the butt but that is
because of how CXF endpoint is setup. That (cxf endpoint setup) is
really the verbose parts of the configuration which do not have default
values.
Can the verbose issue be addressed? Anything that is verbose should be
removed? "The original CXF way" is a CXF user experience. You said CXF
experience is a good thing in Camel Transport' but not in CXF?
On 06/15/2011 09:31 AM, Christian Schneider wrote:
Hi all,
currently we have several ways of using / offering a CXF service with
camel:
- Camel transport for CXF
- cxf: component
- cxfbean: component
- cxfrs: component
The camel transport is useful as it is a very thin layer compared to
the other variants. Additionally it allows to reuse experience from
cxf on how to setup an endpoint.
The cxfbean: component is quite convenient so it makes sense to have it.
The cxfrs: component also seems to be quit econvenient for users.
The cxf: component is very verbose and seems to be used almost exactly
as the original cxf way to describe a service. So I propose to remove
this component. As a migration path I propose users use either the
camel transport for cxf or the cxfbean component.
What do you think?
Christian
