camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Date Thu, 21 Jan 2010 10:23:53 GMT
> Just a quick note for camel-cxf module:
> There are more than 4 components in the camel-cxf
> cxf, cxfrs, cxfbeans, camel transport for cxf , and an unused soap component.

If 'soap' is unused then looks like it can go.
I can see cxfrs has just 10 classes.

> I think we just put them into camel-cxf module because they are CXF related, if there
are many people complain about it introduces 
> lots of third party dependencies we could consider to split them.
> BTW, CXF has a mini bundle which removed more than 20 of cxf modules and can be used
in most case, maybe we could consider to use 
> it.

Indeed, it is a good point, the complete bundle has a number of codegen related dependencies...
And it will not have abdera 
embedded. Worth evaluating this option...

cheers, Sergey

> Willem
> Claus Ibsen wrote:
>> On Thu, Jan 21, 2010 at 10:40 AM, Sergey Beryozkin
>> <> wrote:
>>> See comments with S.B
>>> On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
>>> <> wrote:
>>>> Hi Sergey,
>>>> I am just concerned with the dependencies jaxrs brings into our projects.
>>>> The architects from the projects at my company that use camel and cxf
>>>> complain about the many dependencies needed to simply do web services. So
>>>> I
>>>> am constantly searching how to have less dependencies.
>>>> Currently camel-cxf needs 81 jars.
>>>> When I remove cxf-rt-transports-http-jetty there are 77 jars left.
>>>> When I also remove cxf-rt-frontend-jaxrs there are only 63 jars left.
>>> I totally agree that CXF / camel-cxf is a having way way to many
>>> dependencies out of the box.
>>>> S.B : lets limit the scope of the discussion. Christian has not initiated
>>>> this thread to complain about the fact CXF brings up to 81 jars in total
>>>> rather to raise a valid issue to do with the fact that JAXWS only users get
>>>> up to 10 jars they don't need.
>> CI: I am entitled to pitch in my opinion that camel-cxf which is
>> supposed to be a layer on top of pure CXF to bridge Camel with CXF is
>> using to many jars out of the box. It may be the same if I create a
>> pure CXF java app where being dependent on cxf-core also loads many
>> jars which I may not be interested in using.
>> 81 jars is a fact. Camel only adds camel-cxf.jar, camel-core.jar,
>> camel-spring.jar etc. I assume Christian may or may not have counted
>> those common Spring jars in there as well. And Camel also deps on
>> commons-logging and commons-management. And if using JDK1.5 some JAXB
>> + Activation stuff. But Camel should not bring in more than 8 or so
>> jars.
>> So if I am a JAXWS only user, do I really need 71 jars?
>> Using the old Axis 1.4 did not bring in 71 jars to use.
>>> Unfortunately Maven makes it to easy to not think on how many jars. In
>>> the old days you had to download those .jars yourself and thus you
>>> would notice if using webservice really needs 81 jars?
>>>> S.B : I'm pretty sure a good persentage of those jars is needed by other
>>>> camel components too.
>> CI: I really doubt it. The only shared jars would be Spring and
>> commons-logging, JAXB if using JDK1.5 etc.
>>> I personally want a lightweight webservice stack where I can choose
>>> whether or not I want SOAP over JMS, Mail stuff, WS Security, REST
>>> etc.
>>> In terms of camel-cxf I also think its grew to fat.
>>>> S.B : Really ? Just for fun, how about doing a simple calculation and
>>>> compare a number of jars CXF brings with the number of jars a Camel-based
>>>> application of moderate complexity brings ?
>> CI: I think you misunderstood me. I am talking about camel-cxf is fat
>> in terms of java code.
>> If you see the number of classes it has to bridge Camel with CXF.
>> Dan Kulp is also confused why so many classes is needed.
>> Maybe this should be discussed on a different thread as the original
>> point about 81 jars has nothing to do
>> with the number of classes/code in camel-cxf.
>>> I wonder why thereis so much pluming code in there. I would assume less code
>>> was needed
>>> to bridge the Camel agnostic API with the world of CXF.
>>>> These are still more dependencies than I would like to have but at least
>>>> little better. After removing http-jetty the project still compiles
>>>> without
>>>> problems so I guess it could be removed.
>>>> The jaxrs dependency is currently needed and I guess it is not so easy to
>>>> remove it.
>>>> While checking the dependencies I found that the repo is added in
>>>> camel-cxf. I remember that recently Dan added the jaxb jars to maven
>>>> central
>>>> so I think this repo can now be removed. I checked with an empty local
>>>> repo
>>>> and was able to build camel-cxf.
>>>> Greetings
>>>> Christian
>>>> Am 20.01.2010 10:31, schrieb Sergey Beryozkin:
>>>>>> Hi all,
>>>>>> I am using the camel-cxf component to attach a jaxws service to camel.
>>>>>> Unfortunatelly the camel-cxf component also depends on
>>>>>> cxf-rt-frontend-jaxrs. Is this necessary? It would be nice if this
>>>>>> depdendency could be removed or made optional.
>>>>> Does it cause any issues for you ? Or are you just concerned about extra
>>>>> module being unnecessarily loaded ?
>>>>> I'm not sure it makes sense to introduce another camel component
>>>>> specifically dedicated to handling cxf-rt-frontend-jaxrs.
>>>>> Some users may have JAXWS and JAXRS services attached through a single
>>>>> bean with the help of camel-cxf.
>>>>> cheers, Sergey
>>>> --
>>>> Christian Schneider
>>>> ---
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>> Author of Camel in Action:
>>> Open Source Integration:
>>> Blog:
>>> Twitter:

View raw message