You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Schneider <ch...@die-schneider.net> on 2010/01/20 08:22:54 UTC
Why does camel-cxf need cxf-rt-frontend-jaxrs
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.
Greetings
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Christian
> 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.
cxf-rt-frontend-jaxrs brings in aegis/xmlbeans/abdera/jettison but as far as CXF JAX-RS is concerned those dependencies do not have
to be strictly available at runtime. ServiceMix cxf jaxrs feature adds the corresponding bundles at its init time.
Thus camel-cxf pom can be updated to exclude abdera/jettison and say aegis and possibly xmlbeans, would be up to 10 jars (abdera has
4/5 jars). Non ServiceMix camel-cxf users can add abdera/jettison dependencies if needed - perhaps camel users shoudl get an email
in case such users who do expect camel-cxf to bring in abdera/jettison exist.
Willem - do you agree ?
cheers, Sergey
>
> These are still more dependencies than I would like to have but at least a 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 java.net 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
> ---
> http://www.liquid-reality.de
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Willem Jiang <wi...@gmail.com>.
Hi Christian,
You can try to use the cxf bundle jar which will reduce lots of the jar
head. You can find the jar dependency from camel-cxf section of the
features.xml[1]
[1]
https://svn.apache.org/repos/asf/camel/trunk/platforms/karaf/features/src/main/resources/features.xml
Willem
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.
>
> These are still more dependencies than I would like to have but at least
> a 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 java.net 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
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Willem Jiang <wi...@gmail.com>.
Claus Ibsen wrote:
> On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
> <ch...@die-schneider.net> 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.
> 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?
>
> 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. I wonder why there
> is so much pluming code in there. I would assume less code was needed
> to bridge the Camel agnostic API with the world of CXF.
>
There are different ways to integration CXF with Camel, you can deploy a
service bean with the camel context CXF; you can let the camel context
to start up the CXF endpoints; you can also leverage the camel
components to provides transport services for the CXF endpoints.
What we do in camel-cxf is trying to connect the world of CXF and Camel
together, which means people's knowledge of CXF (such as configuration,
terms, etc) can be transparently used into camel-cxf endpoint, and the
user of camel-cxf can talk to other camel component and CXF without any
issue.
As you know CXF has lots front ends and APIs, we can't just isolate our
interaction with a single cxf-api or cxf-core, and some advance features
require us to get touch with internal API of CXF.
It will make the life easier, if we just use the JAXWS API, but
camel-cxf component will not support some other feature of CXF, such as
JAXRS, simple front end API ...
I'm big fan of KISS principle, if we just want a simple piece of SOAP
support, we don't need to bring a huge frame work before the user, and
we do it easily and cleanly.
But if the user is getting familiar with so kind of framework, they may
ask for more support in camel-xxx.
>
>> These are still more dependencies than I would like to have but at least a
>> 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 java.net 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
>> ---
>> http://www.liquid-reality.de
>>
>>
>
>
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
> 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
>> <sb...@progress.com> wrote:
>>> See comments with S.B
>>>
>>>
>>> On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
>>> <ch...@die-schneider.net> 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 but
>>>> 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 a
>>>> 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 java.net 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
>>>> ---
>>>> http://www.liquid-reality.de
>>>>
>>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>
>>
>>
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Willem Jiang <wi...@gmail.com>.
As CXF supports lots of other API, just one simpel cxf-api and cxf-core
can't provides what we want to in camel-cxf :(
Christian, I checked the camel-cxf pom.xml, if you want to use the CXF
mini bundle , you just need to exclude below module, but you may need to
add some other third part dependencies to let CXF run.
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cxf</artifactId>
<version>${camel-version}</version>
<exclusions>
<exclusion>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxrs</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle-minimal</artifactId>
<version>${cxf-version}</version>
</dependency>
Willem
Christian Schneider wrote:
> While I think it is great that a mini bundle is there for some special
> cases I think it should possible to make the modular version more
> independent of external libs. Especially the cxf api and core should
> have no dependencies. Spring and camel have also achieved this. Having
> said this I know it is a lot of work ;-(
>
> Greetings
>
> Christian
>
> Am 21.01.2010 11:10, schrieb Willem Jiang:
>> 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.
>>
>> 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.
>>
>> Willem
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Christian Schneider <ch...@die-schneider.net>.
While I think it is great that a mini bundle is there for some special
cases I think it should possible to make the modular version more
independent of external libs. Especially the cxf api and core should
have no dependencies. Spring and camel have also achieved this. Having
said this I know it is a lot of work ;-(
Greetings
Christian
Am 21.01.2010 11:10, schrieb Willem Jiang:
> 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.
>
> 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.
>
> Willem
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Willem Jiang <wi...@gmail.com>.
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.
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.
Willem
Claus Ibsen wrote:
> On Thu, Jan 21, 2010 at 10:40 AM, Sergey Beryozkin
> <sb...@progress.com> wrote:
>> See comments with S.B
>>
>>
>> On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
>> <ch...@die-schneider.net> 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 but
>>> 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 a
>>> 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 java.net 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
>>> ---
>>> http://www.liquid-reality.de
>>>
>>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
>
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Jan 21, 2010 at 11:09 AM, Sergey Beryozkin
<sb...@progress.com> wrote:
>>>
>>> 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
>>>> but
>>>> 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.
>
> ok...
>
>>
>> 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.
>>
>
> So what ? Users use CXF to get a high quality web services support. Some of
> these jars are specs, some are needed to let users do advanced services.
> Users can exclude the jars they do not need. Camel can have an axis 1.4
> component for users who like Axis.
>
People doing integration application may very well be accounted for
their applications they build and those 3rd part frameworks they chose
to use as well.
They may very well look into which artifacts they bring into
production and license implications using them etc. Also the maturity,
quality, activity, etc. for those artifacts as well. Having to go over
as few as possible artifacts and using best of breads artifacts is for
most people a good thing.
Having to trim down from a high number of artifacts may be a time
consuming tasks. How can you verify in a reliable manner which
artifacts you can trim?
Not everybody is maven ninjas or using maven at all.
And how do you manage using the most stable of all those jars as well?
Project X may by default include older releases containing bugs which
could affect your application etc.
I will consider it a drawback for product X if it depends on a high
number of artifacts. If it did I would like to see some documentation
which explains in details why all those artifacts is needed. And if
possible which ones are needed in which scenarios.
Notice this is a general point of view which is targeted for all
projects and not specific camel-cxf or CXF.
I have been in charge of integration projects where artifacts must be
on a "green" list before it can be used etc.
And I am sure this practice is still applied out there.
So it may not always be possible to use product X because of conflicts
which such a "green" list.
>>
>>> 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.
>
> ok...
>
>>
>>
>>> 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.
>
> I see...
>
>> 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
>>>> a
>>>> 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 java.net 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
>>>> ---
>>>> http://www.liquid-reality.de
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Willem Jiang <wi...@gmail.com>.
We can split the transport part out camel-cxf, but consider the backward
compatibility, we may do it in camel 2.3 or camel 3.0.
I already create a JIRA[1] for it.
[1]https://issues.apache.org/activemq/browse/CAMEL-2389
Willem
Christian Schneider wrote:
> Am 21.01.2010 15:01, schrieb Hadrian Zbarcea:
>>
>> Christian, since you brought this up, what do you think a reasonable
>> solution for you would be?
>>
>>
> Hi Hadrian,
>
> Ideally I would like to have a camel-cxf component that only adapts
> camel to cxf. So this component would need neither of
> cxf-rt-frontend-jaxrs nor cxf-rt-frontend-jaxws. I do not know if this
> is possbile though. I think the problem is that camel-cxf supports both
> cxfendpoints and the cxf camel transport. Perhaps this would be a nice
> oportunity to split. I am not sure but I think the camel tranport for
> cxf could be independent of jaxws and jaxrs. As this is the only thing
> we currently use it would help a lot to have it in a separate module.
>
> Btw. talking about dependencies I think camel really shines. I have
> checked a project that depends on camel-core, camel-jms and camel-jaxb.
> It gives me the dependencies below. Apart from spring it is almost
> impossible to have less dependencies. As most of our projects use spring
> anyway the dependency on spring is not a real problem for us.
>
> Greetings
>
> Christian
>
> -----
> aopalliance:aopalliance:jar:1.0:compile
> com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
> commons-logging:commons-logging:jar:1.1.1:compile
> commons-logging:commons-logging-api:jar:1.1:compile
> commons-pool:commons-pool:jar:1.3:compile
> javax.activation:activation:jar:1.1:compile
> javax.xml.bind:jaxb-api:jar:2.1:compile
> javax.xml.stream:stax-api:jar:1.0-2:compile
> org.apache.camel:camel-core:jar:1.4.0:compile
> org.apache.camel:camel-jaxb:jar:1.4.0:compile
> org.apache.camel:camel-jms:jar:1.4.0:compile
> org.apache.camel:camel-spring:jar:1.4.0:compile
> org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1.1:compile
> org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile
> org.springframework:spring-aop:jar:2.5.5:compile
> org.springframework:spring-beans:jar:2.5.5:compile
> org.springframework:spring-context:jar:2.5.5:compile
> org.springframework:spring-context-support:jar:2.5.5:compile
> org.springframework:spring-core:jar:2.5.5:compile
> org.springframework:spring-jms:jar:2.5.5:compile
> org.springframework:spring-tx:jar:2.5.5:compile
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 21.01.2010 15:01, schrieb Hadrian Zbarcea:
>
> Christian, since you brought this up, what do you think a reasonable solution for you would be?
>
>
Hi Hadrian,
Ideally I would like to have a camel-cxf component that only adapts
camel to cxf. So this component would need neither of
cxf-rt-frontend-jaxrs nor cxf-rt-frontend-jaxws. I do not know if this
is possbile though. I think the problem is that camel-cxf supports both
cxfendpoints and the cxf camel transport. Perhaps this would be a nice
oportunity to split. I am not sure but I think the camel tranport for
cxf could be independent of jaxws and jaxrs. As this is the only thing
we currently use it would help a lot to have it in a separate module.
Btw. talking about dependencies I think camel really shines. I have
checked a project that depends on camel-core, camel-jms and camel-jaxb.
It gives me the dependencies below. Apart from spring it is almost
impossible to have less dependencies. As most of our projects use spring
anyway the dependency on spring is not a real problem for us.
Greetings
Christian
-----
aopalliance:aopalliance:jar:1.0:compile
com.sun.xml.bind:jaxb-impl:jar:2.1.6:compile
commons-logging:commons-logging:jar:1.1.1:compile
commons-logging:commons-logging-api:jar:1.1:compile
commons-pool:commons-pool:jar:1.3:compile
javax.activation:activation:jar:1.1:compile
javax.xml.bind:jaxb-api:jar:2.1:compile
javax.xml.stream:stax-api:jar:1.0-2:compile
org.apache.camel:camel-core:jar:1.4.0:compile
org.apache.camel:camel-jaxb:jar:1.4.0:compile
org.apache.camel:camel-jms:jar:1.4.0:compile
org.apache.camel:camel-spring:jar:1.4.0:compile
org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1.1:compile
org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile
org.springframework:spring-aop:jar:2.5.5:compile
org.springframework:spring-beans:jar:2.5.5:compile
org.springframework:spring-context:jar:2.5.5:compile
org.springframework:spring-context-support:jar:2.5.5:compile
org.springframework:spring-core:jar:2.5.5:compile
org.springframework:spring-jms:jar:2.5.5:compile
org.springframework:spring-tx:jar:2.5.5:compile
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <se...@iona.com>.
> I think the only option is to split JAXRS and JAXWS into different maven
projects if number of jars/dependencies is a concern.
Or exclude some of the jars from cxf-frontend-jaxrs as I suggested to Willem
? Thus advanced users will just get a couple of extra jars.
William Tam wrote:
>
> If you look at the runtime dependencies, there are not that many. I
> think the only option is to split JAXRS and JAXWS into different maven
> projects if number of jars/dependencies is a concern.
>
> <dependency>
> <groupId>org.apache.camel</groupId>
> <artifactId>camel-core</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.apache.camel</groupId>
> <artifactId>camel-spring</artifactId>
> </dependency>
>
> <dependency>
> <groupId>commons-logging</groupId>
> <artifactId>commons-logging-api</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-rt-frontend-jaxrs</artifactId>
> <version>${cxf-version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-rt-transports-http-jetty</artifactId>
> <version>${cxf-version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cxf</groupId>
> <artifactId>cxf-rt-frontend-jaxws</artifactId>
> <version>${cxf-version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-core</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-beans</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.springframework</groupId>
> <artifactId>spring-context</artifactId>
> </dependency>
>
>
> Hadrian Zbarcea wrote:
>> Chill...
>>
>> Christian made a valid point. There are a few *types* of dependencies in
>> Camel:
>> 1. compile dependencies - which cannot be avoided and should be kept to a
>> minimum
>> 2. test runtime dependencies - needed for tests, which again cannot be
>> avoided but should be tagged as such in the pom, and i am pretty sure
>> some dependencies are only needed by tests, so users don't need to drag
>> them along
>> 3. user runtime dependencies - jars not really needed by camel, not even
>> for tests, but which customers may need to use features in the underlying
>> technology abstracted by camel.
>>
>> Since camel intends to abstract a particular technology, how much of
>> abstraction leak is acceptable? That is how much is it reasonable to
>> expect a user to know about the underlying technology (cxf packaging and
>> dependencies in this case) to effectively use it? The cxf guys made a
>> conscious decision a few years back to use fine grained jars, which are
>> small, can be combined in various ways and make cxf more efficient, with
>> a smaller footprint at runtime and probably faster. Definitely good
>> things for cxf. Does this make things more complicated for Camel? Of
>> course it does. Unfortunately there's no easy solution. Some advanced
>> users, like Christian, would want the optimized minimum, others would
>> prefer the convenience of "throw them all in there and camel will load
>> what it needs".
>>
>> Christian, since you brought this up, what do you think a reasonable
>> solution for you would be?
>>
>> Hadrian
>>
>>
>> On Jan 21, 2010, at 5:09 AM, Sergey Beryozkin wrote:
>>
>>
>>>>> 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 but
>>>>>> 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.
>>>>
>>> ok...
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> So what ? Users use CXF to get a high quality web services support. Some
>>> of these jars are specs, some are needed to let users do advanced
>>> services. Users can exclude the jars they do not need. Camel can have an
>>> axis 1.4 component for users who like Axis.
>>>
>>>
>>>>> 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.
>>>>
>>> ok...
>>>
>>>
>>>>
>>>>> 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.
>>>>
>>> I see...
>>>
>>>
>>>> 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 a
>>>>>> 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 java.net 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
>>>>>> ---
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>>
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>>
>>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>>
>>
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Why-does-camel-cxf-need-cxf-rt-frontend-jaxrs-tp27237712p27260617.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by William Tam <em...@gmail.com>.
If you look at the runtime dependencies, there are not that many. I
think the only option is to split JAXRS and JAXWS into different maven
projects if number of jars/dependencies is a concern.
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring</artifactId>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxrs</artifactId>
<version>${cxf-version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-jetty</artifactId>
<version>${cxf-version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>${cxf-version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
Hadrian Zbarcea wrote:
> Chill...
>
> Christian made a valid point. There are a few *types* of dependencies in Camel:
> 1. compile dependencies - which cannot be avoided and should be kept to a minimum
> 2. test runtime dependencies - needed for tests, which again cannot be avoided but should be tagged as such in the pom, and i am pretty sure some dependencies are only needed by tests, so users don't need to drag them along
> 3. user runtime dependencies - jars not really needed by camel, not even for tests, but which customers may need to use features in the underlying technology abstracted by camel.
>
> Since camel intends to abstract a particular technology, how much of abstraction leak is acceptable? That is how much is it reasonable to expect a user to know about the underlying technology (cxf packaging and dependencies in this case) to effectively use it? The cxf guys made a conscious decision a few years back to use fine grained jars, which are small, can be combined in various ways and make cxf more efficient, with a smaller footprint at runtime and probably faster. Definitely good things for cxf. Does this make things more complicated for Camel? Of course it does. Unfortunately there's no easy solution. Some advanced users, like Christian, would want the optimized minimum, others would prefer the convenience of "throw them all in there and camel will load what it needs".
>
> Christian, since you brought this up, what do you think a reasonable solution for you would be?
>
> Hadrian
>
>
> On Jan 21, 2010, at 5:09 AM, Sergey Beryozkin wrote:
>
>
>>>> 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 but
>>>>> 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.
>>>
>> ok...
>>
>>
>>> 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.
>>>
>>>
>> So what ? Users use CXF to get a high quality web services support. Some of these jars are specs, some are needed to let users do advanced services. Users can exclude the jars they do not need. Camel can have an axis 1.4 component for users who like Axis.
>>
>>
>>>> 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.
>>>
>> ok...
>>
>>
>>>
>>>> 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.
>>>
>> I see...
>>
>>
>>> 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 a
>>>>> 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 java.net 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
>>>>> ---
>>>>> http://www.liquid-reality.de
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>>
>>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>
>
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Chill...
Christian made a valid point. There are a few *types* of dependencies in Camel:
1. compile dependencies - which cannot be avoided and should be kept to a minimum
2. test runtime dependencies - needed for tests, which again cannot be avoided but should be tagged as such in the pom, and i am pretty sure some dependencies are only needed by tests, so users don't need to drag them along
3. user runtime dependencies - jars not really needed by camel, not even for tests, but which customers may need to use features in the underlying technology abstracted by camel.
Since camel intends to abstract a particular technology, how much of abstraction leak is acceptable? That is how much is it reasonable to expect a user to know about the underlying technology (cxf packaging and dependencies in this case) to effectively use it? The cxf guys made a conscious decision a few years back to use fine grained jars, which are small, can be combined in various ways and make cxf more efficient, with a smaller footprint at runtime and probably faster. Definitely good things for cxf. Does this make things more complicated for Camel? Of course it does. Unfortunately there's no easy solution. Some advanced users, like Christian, would want the optimized minimum, others would prefer the convenience of "throw them all in there and camel will load what it needs".
Christian, since you brought this up, what do you think a reasonable solution for you would be?
Hadrian
On Jan 21, 2010, at 5:09 AM, Sergey Beryozkin wrote:
>>>
>>> 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 but
>>>> 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.
>
> ok...
>
>>
>> 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.
>>
>
> So what ? Users use CXF to get a high quality web services support. Some of these jars are specs, some are needed to let users do advanced services. Users can exclude the jars they do not need. Camel can have an axis 1.4 component for users who like Axis.
>
>>
>>> 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.
>
> ok...
>
>>
>>
>>> 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.
>
> I see...
>
>> 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 a
>>>> 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 java.net 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
>>>> ---
>>>> http://www.liquid-reality.de
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
>>
>> 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 but
>>> 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.
ok...
>
> 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.
>
So what ? Users use CXF to get a high quality web services support. Some of these jars are specs, some are needed to let users do
advanced services. Users can exclude the jars they do not need. Camel can have an axis 1.4 component for users who like Axis.
>
>> 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.
ok...
>
>
>> 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.
I see...
> 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 a
>>> 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 java.net 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
>>> ---
>>> http://www.liquid-reality.de
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Jan 21, 2010 at 10:40 AM, Sergey Beryozkin
<sb...@progress.com> wrote:
> See comments with S.B
>
>
> On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
> <ch...@die-schneider.net> 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 but
>> 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 a
>> 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 java.net 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
>> ---
>> http://www.liquid-reality.de
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
See comments with S.B
On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
<ch...@die-schneider.net> 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 but rather to raise a valid issue to do with the fact that JAXWS only users get up to 10 jars they don't need.
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.
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 ?
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 a
> 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 java.net 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
> ---
> http://www.liquid-reality.de
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Jan 20, 2010 at 11:51 PM, Christian Schneider
<ch...@die-schneider.net> 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.
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?
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. I wonder why there
is 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 a
> 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 java.net 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
> ---
> http://www.liquid-reality.de
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
These are still more dependencies than I would like to have but at least
a 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 java.net 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
---
http://www.liquid-reality.de
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
> 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
>
> Greetings
>
> Christian
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Willem Jiang <wi...@gmail.com>.
I think xmlbeans is optional, but as we use the simple front end API to
create producer and consumer, the other jars are required.
Willem
Sergey Beryozkin wrote:
> Hi Hadrian
>
> I'm not exactly sure about these 3 :
>
>>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>
> The first 1 might be ok to be excluded (this one probably gets included
> through cxf-rt-fronend-jaxrs), but Willem mentioned a simple frontend
> earlier on (which also depends on Aegis) so may be the last 2 can stay
> if there're camelcxf/simple frontend users out there but excluded if not
>
> thanks, Sergey
>
> ----- Original Message ----- From: "Hadrian Zbarcea" <hz...@gmail.com>
> To: <de...@camel.apache.org>
> Sent: Monday, January 25, 2010 3:17 PM
> Subject: Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
>
>
> Thanks Sergey! This is very helpful.
> I am messing with the camel poms today anyway and I will try the
> suggested change.
>
> Cheers,
> Hadrian
>
> On Jan 25, 2010, at 4:52 AM, Sergey Beryozkin wrote:
>
>> Hi
>>
>> as suggested earlier on, the following dependencies can also be
>> exclused from cxf-rt-frontend-jaxrs in a camel-cxf pom :
>>
>>> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
>>> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
>>> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
>>> org.codehaus.jettison:jettison:jar:1.2:compile
>>
>> ServiceMix cxf jaxrs feature will add abdera and jettison, other
>> users who might be using camel-cxf and jaxrs and expecting camel-cxf
>> to bring in abdera/jettison would need to add explicit dependencies.
>>
>> these are also possible candidates :
>>
>>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>>
>> After the above exclusions, cxfrs component will only contribute 2 or
>> so jars to the total,
>>
>> cheers, Sergey
>>
>>
>>> I just experimentally created a camel-cxf-camel-transport component
>>> that only implements the camel transport for cxf.
>>>
>>> The compile dependencies go down from 54 for camel-cxf to 27 for the
>>> new component.
>>> I added the dependencies below.
>>>
>>> Greetings
>>>
>>> Christian
>>> ----
>>> mvn dependency:list -DincludeScope=compile
>>>
>>> camel-cxf-camel-transport:
>>> aopalliance:aopalliance:jar:1.0:compile
>>> com.sun:tools:jar:1.5.0:system
>>> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
>>> commons-lang:commons-lang:jar:2.4:compile
>>> commons-logging:commons-logging-api:jar:1.1:compile
>>> javax.xml.bind:jaxb-api:jar:2.1:compile
>>> javax.xml.soap:saaj-api:jar:1.3:compile
>>> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
>>> org.apache.cxf:cxf-api:jar:2.2.5:compile
>>> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
>>> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
>>> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
>>> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
>>> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
>>> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
>>> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
>>> org.apache.neethi:neethi:jar:2.0.4:compile
>>> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
>>> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
>>> org.fusesource.commonman:commons-management:jar:1.0:compile
>>> org.springframework:spring-beans:jar:2.5.6:compile
>>> org.springframework:spring-context:jar:2.5.6:compile
>>> org.springframework:spring-core:jar:2.5.6:compile
>>> wsdl4j:wsdl4j:jar:1.6.2:compile
>>>
>>> camel-cxf:
>>> aopalliance:aopalliance:jar:1.0:compile
>>> asm:asm:jar:2.2.3:compile
>>> com.sun:tools:jar:1.5.0:system
>>> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
>>> com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:compile
>>> commons-codec:commons-codec:jar:1.2:compile
>>> commons-lang:commons-lang:jar:2.4:compile
>>> commons-logging:commons-logging-api:jar:1.1:compile
>>> javax.ws.rs:jsr311-api:jar:1.0:compile
>>> javax.xml.bind:jaxb-api:jar:2.1:compile
>>> javax.xml.soap:saaj-api:jar:1.3:compile
>>> jaxen:jaxen:jar:1.1.1:compile
>>> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
>>> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
>>> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
>>> org.apache.camel:camel-spring:jar:2.2-SNAPSHOT:compile
>>> org.apache.cxf:cxf-api:jar:2.2.5:compile
>>> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
>>> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-bindings-xml:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-transports-http:jar:2.2.5:compile
>>> org.apache.cxf:cxf-rt-ws-addr:jar:2.2.5:compile
>>> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
>>> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
>>> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
>>> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
>>> org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile
>>> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
>>> org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2:compile
>>>
>>> org.apache.neethi:neethi:jar:2.0.4:compile
>>> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
>>> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
>>> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
>>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>>> org.codehaus.jettison:jettison:jar:1.2:compile
>>> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
>>> org.fusesource.commonman:commons-management:jar:1.0:compile
>>> org.springframework:spring-aop:jar:2.5.6:compile
>>> org.springframework:spring-beans:jar:2.5.6:compile
>>> org.springframework:spring-context:jar:2.5.6:compile
>>> org.springframework:spring-core:jar:2.5.6:compile
>>> org.springframework:spring-tx:jar:2.5.6:compile
>>> wsdl4j:wsdl4j:jar:1.6.2:compile
>>> xml-resolver:xml-resolver:jar:1.2:compile
>>>
>>> Am 20.01.2010 08:22, schrieb Christian Schneider:
>>>> 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.
>>>>
>>>> Greetings
>>>>
>>>> Christian
>>>>
>>>
>>>
>>> --
>>>
>>> Christian Schneider
>>> ---
>>> http://www.liquid-reality.de
>>
>
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Hadrian
I'm not exactly sure about these 3 :
>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
The first 1 might be ok to be excluded (this one probably gets included through cxf-rt-fronend-jaxrs), but Willem mentioned a simple
frontend earlier on (which also depends on Aegis) so may be the last 2 can stay if there're camelcxf/simple frontend users out there
but excluded if not
thanks, Sergey
----- Original Message -----
From: "Hadrian Zbarcea" <hz...@gmail.com>
To: <de...@camel.apache.org>
Sent: Monday, January 25, 2010 3:17 PM
Subject: Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Thanks Sergey! This is very helpful.
I am messing with the camel poms today anyway and I will try the suggested change.
Cheers,
Hadrian
On Jan 25, 2010, at 4:52 AM, Sergey Beryozkin wrote:
> Hi
>
> as suggested earlier on, the following dependencies can also be exclused from cxf-rt-frontend-jaxrs in a camel-cxf pom :
>
>> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
>> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
>> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
>> org.codehaus.jettison:jettison:jar:1.2:compile
>
> ServiceMix cxf jaxrs feature will add abdera and jettison, other users who might be using camel-cxf and jaxrs and expecting
> camel-cxf to bring in abdera/jettison would need to add explicit dependencies.
>
> these are also possible candidates :
>
>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>
> After the above exclusions, cxfrs component will only contribute 2 or so jars to the total,
>
> cheers, Sergey
>
>
>> I just experimentally created a camel-cxf-camel-transport component that only implements the camel transport for cxf.
>>
>> The compile dependencies go down from 54 for camel-cxf to 27 for the new component.
>> I added the dependencies below.
>>
>> Greetings
>>
>> Christian
>> ----
>> mvn dependency:list -DincludeScope=compile
>>
>> camel-cxf-camel-transport:
>> aopalliance:aopalliance:jar:1.0:compile
>> com.sun:tools:jar:1.5.0:system
>> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
>> commons-lang:commons-lang:jar:2.4:compile
>> commons-logging:commons-logging-api:jar:1.1:compile
>> javax.xml.bind:jaxb-api:jar:2.1:compile
>> javax.xml.soap:saaj-api:jar:1.3:compile
>> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
>> org.apache.cxf:cxf-api:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
>> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
>> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
>> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
>> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
>> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
>> org.apache.neethi:neethi:jar:2.0.4:compile
>> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
>> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
>> org.fusesource.commonman:commons-management:jar:1.0:compile
>> org.springframework:spring-beans:jar:2.5.6:compile
>> org.springframework:spring-context:jar:2.5.6:compile
>> org.springframework:spring-core:jar:2.5.6:compile
>> wsdl4j:wsdl4j:jar:1.6.2:compile
>>
>> camel-cxf:
>> aopalliance:aopalliance:jar:1.0:compile
>> asm:asm:jar:2.2.3:compile
>> com.sun:tools:jar:1.5.0:system
>> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
>> com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:compile
>> commons-codec:commons-codec:jar:1.2:compile
>> commons-lang:commons-lang:jar:2.4:compile
>> commons-logging:commons-logging-api:jar:1.1:compile
>> javax.ws.rs:jsr311-api:jar:1.0:compile
>> javax.xml.bind:jaxb-api:jar:2.1:compile
>> javax.xml.soap:saaj-api:jar:1.3:compile
>> jaxen:jaxen:jar:1.1.1:compile
>> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
>> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
>> org.apache.camel:camel-spring:jar:2.2-SNAPSHOT:compile
>> org.apache.cxf:cxf-api:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-bindings-xml:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-transports-http:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-ws-addr:jar:2.2.5:compile
>> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
>> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
>> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
>> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
>> org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile
>> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
>> org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2:compile
>> org.apache.neethi:neethi:jar:2.0.4:compile
>> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
>> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
>> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>> org.codehaus.jettison:jettison:jar:1.2:compile
>> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
>> org.fusesource.commonman:commons-management:jar:1.0:compile
>> org.springframework:spring-aop:jar:2.5.6:compile
>> org.springframework:spring-beans:jar:2.5.6:compile
>> org.springframework:spring-context:jar:2.5.6:compile
>> org.springframework:spring-core:jar:2.5.6:compile
>> org.springframework:spring-tx:jar:2.5.6:compile
>> wsdl4j:wsdl4j:jar:1.6.2:compile
>> xml-resolver:xml-resolver:jar:1.2:compile
>>
>> Am 20.01.2010 08:22, schrieb Christian Schneider:
>>> 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.
>>>
>>> Greetings
>>>
>>> Christian
>>>
>>
>>
>> --
>>
>> Christian Schneider
>> ---
>> http://www.liquid-reality.de
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Thanks Sergey! This is very helpful.
I am messing with the camel poms today anyway and I will try the suggested change.
Cheers,
Hadrian
On Jan 25, 2010, at 4:52 AM, Sergey Beryozkin wrote:
> Hi
>
> as suggested earlier on, the following dependencies can also be exclused from cxf-rt-frontend-jaxrs in a camel-cxf pom :
>
>> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
>> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
>> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
>> org.codehaus.jettison:jettison:jar:1.2:compile
>
> ServiceMix cxf jaxrs feature will add abdera and jettison, other users who might be using camel-cxf and jaxrs and expecting camel-cxf to bring in abdera/jettison would need to add explicit dependencies.
>
> these are also possible candidates :
>
>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>
> After the above exclusions, cxfrs component will only contribute 2 or so jars to the total,
>
> cheers, Sergey
>
>
>> I just experimentally created a camel-cxf-camel-transport component that only implements the camel transport for cxf.
>>
>> The compile dependencies go down from 54 for camel-cxf to 27 for the new component.
>> I added the dependencies below.
>>
>> Greetings
>>
>> Christian
>> ----
>> mvn dependency:list -DincludeScope=compile
>>
>> camel-cxf-camel-transport:
>> aopalliance:aopalliance:jar:1.0:compile
>> com.sun:tools:jar:1.5.0:system
>> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
>> commons-lang:commons-lang:jar:2.4:compile
>> commons-logging:commons-logging-api:jar:1.1:compile
>> javax.xml.bind:jaxb-api:jar:2.1:compile
>> javax.xml.soap:saaj-api:jar:1.3:compile
>> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
>> org.apache.cxf:cxf-api:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
>> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
>> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
>> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
>> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
>> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
>> org.apache.neethi:neethi:jar:2.0.4:compile
>> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
>> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
>> org.fusesource.commonman:commons-management:jar:1.0:compile
>> org.springframework:spring-beans:jar:2.5.6:compile
>> org.springframework:spring-context:jar:2.5.6:compile
>> org.springframework:spring-core:jar:2.5.6:compile
>> wsdl4j:wsdl4j:jar:1.6.2:compile
>>
>> camel-cxf:
>> aopalliance:aopalliance:jar:1.0:compile
>> asm:asm:jar:2.2.3:compile
>> com.sun:tools:jar:1.5.0:system
>> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
>> com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:compile
>> commons-codec:commons-codec:jar:1.2:compile
>> commons-lang:commons-lang:jar:2.4:compile
>> commons-logging:commons-logging-api:jar:1.1:compile
>> javax.ws.rs:jsr311-api:jar:1.0:compile
>> javax.xml.bind:jaxb-api:jar:2.1:compile
>> javax.xml.soap:saaj-api:jar:1.3:compile
>> jaxen:jaxen:jar:1.1.1:compile
>> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
>> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
>> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
>> org.apache.camel:camel-spring:jar:2.2-SNAPSHOT:compile
>> org.apache.cxf:cxf-api:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
>> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-bindings-xml:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-transports-http:jar:2.2.5:compile
>> org.apache.cxf:cxf-rt-ws-addr:jar:2.2.5:compile
>> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
>> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
>> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
>> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
>> org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile
>> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
>> org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2:compile
>> org.apache.neethi:neethi:jar:2.0.4:compile
>> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
>> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
>> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
>> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
>> org.codehaus.jettison:jettison:jar:1.2:compile
>> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
>> org.fusesource.commonman:commons-management:jar:1.0:compile
>> org.springframework:spring-aop:jar:2.5.6:compile
>> org.springframework:spring-beans:jar:2.5.6:compile
>> org.springframework:spring-context:jar:2.5.6:compile
>> org.springframework:spring-core:jar:2.5.6:compile
>> org.springframework:spring-tx:jar:2.5.6:compile
>> wsdl4j:wsdl4j:jar:1.6.2:compile
>> xml-resolver:xml-resolver:jar:1.2:compile
>>
>> Am 20.01.2010 08:22, schrieb Christian Schneider:
>>> 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.
>>>
>>> Greetings
>>>
>>> Christian
>>>
>>
>>
>> --
>>
>> Christian Schneider
>> ---
>> http://www.liquid-reality.de
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
as suggested earlier on, the following dependencies can also be exclused from cxf-rt-frontend-jaxrs in a camel-cxf pom :
> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
> org.codehaus.jettison:jettison:jar:1.2:compile
ServiceMix cxf jaxrs feature will add abdera and jettison, other users who might be using camel-cxf and jaxrs and expecting
camel-cxf to bring in abdera/jettison would need to add explicit dependencies.
these are also possible candidates :
> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
After the above exclusions, cxfrs component will only contribute 2 or so jars to the total,
cheers, Sergey
>I just experimentally created a camel-cxf-camel-transport component that only implements the camel transport for cxf.
>
> The compile dependencies go down from 54 for camel-cxf to 27 for the new component.
> I added the dependencies below.
>
> Greetings
>
> Christian
> ----
> mvn dependency:list -DincludeScope=compile
>
> camel-cxf-camel-transport:
> aopalliance:aopalliance:jar:1.0:compile
> com.sun:tools:jar:1.5.0:system
> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
> commons-lang:commons-lang:jar:2.4:compile
> commons-logging:commons-logging-api:jar:1.1:compile
> javax.xml.bind:jaxb-api:jar:2.1:compile
> javax.xml.soap:saaj-api:jar:1.3:compile
> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
> org.apache.cxf:cxf-api:jar:2.2.5:compile
> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
> org.apache.neethi:neethi:jar:2.0.4:compile
> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
> org.fusesource.commonman:commons-management:jar:1.0:compile
> org.springframework:spring-beans:jar:2.5.6:compile
> org.springframework:spring-context:jar:2.5.6:compile
> org.springframework:spring-core:jar:2.5.6:compile
> wsdl4j:wsdl4j:jar:1.6.2:compile
>
> camel-cxf:
> aopalliance:aopalliance:jar:1.0:compile
> asm:asm:jar:2.2.3:compile
> com.sun:tools:jar:1.5.0:system
> com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
> com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:compile
> commons-codec:commons-codec:jar:1.2:compile
> commons-lang:commons-lang:jar:2.4:compile
> commons-logging:commons-logging-api:jar:1.1:compile
> javax.ws.rs:jsr311-api:jar:1.0:compile
> javax.xml.bind:jaxb-api:jar:2.1:compile
> javax.xml.soap:saaj-api:jar:1.3:compile
> jaxen:jaxen:jar:1.1.1:compile
> org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
> org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
> org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
> org.apache.camel:camel-spring:jar:2.2-SNAPSHOT:compile
> org.apache.cxf:cxf-api:jar:2.2.5:compile
> org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
> org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-bindings-xml:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-transports-http:jar:2.2.5:compile
> org.apache.cxf:cxf-rt-ws-addr:jar:2.2.5:compile
> org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
> org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
> org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
> org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
> org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2:compile
> org.apache.neethi:neethi:jar:2.0.4:compile
> org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
> org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
> org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
> org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
> org.codehaus.jettison:jettison:jar:1.2:compile
> org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
> org.fusesource.commonman:commons-management:jar:1.0:compile
> org.springframework:spring-aop:jar:2.5.6:compile
> org.springframework:spring-beans:jar:2.5.6:compile
> org.springframework:spring-context:jar:2.5.6:compile
> org.springframework:spring-core:jar:2.5.6:compile
> org.springframework:spring-tx:jar:2.5.6:compile
> wsdl4j:wsdl4j:jar:1.6.2:compile
> xml-resolver:xml-resolver:jar:1.2:compile
>
> Am 20.01.2010 08:22, schrieb Christian Schneider:
>> 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.
>>
>> Greetings
>>
>> Christian
>>
>
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
Re: Why does camel-cxf need cxf-rt-frontend-jaxrs
Posted by Christian Schneider <ch...@die-schneider.net>.
I just experimentally created a camel-cxf-camel-transport component that
only implements the camel transport for cxf.
The compile dependencies go down from 54 for camel-cxf to 27 for the new
component.
I added the dependencies below.
Greetings
Christian
----
mvn dependency:list -DincludeScope=compile
camel-cxf-camel-transport:
aopalliance:aopalliance:jar:1.0:compile
com.sun:tools:jar:1.5.0:system
com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
commons-lang:commons-lang:jar:2.4:compile
commons-logging:commons-logging-api:jar:1.1:compile
javax.xml.bind:jaxb-api:jar:2.1:compile
javax.xml.soap:saaj-api:jar:1.3:compile
org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
org.apache.cxf:cxf-api:jar:2.2.5:compile
org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
org.apache.neethi:neethi:jar:2.0.4:compile
org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
org.fusesource.commonman:commons-management:jar:1.0:compile
org.springframework:spring-beans:jar:2.5.6:compile
org.springframework:spring-context:jar:2.5.6:compile
org.springframework:spring-core:jar:2.5.6:compile
wsdl4j:wsdl4j:jar:1.6.2:compile
camel-cxf:
aopalliance:aopalliance:jar:1.0:compile
asm:asm:jar:2.2.3:compile
com.sun:tools:jar:1.5.0:system
com.sun.xml.bind:jaxb-impl:jar:2.1.12:compile
com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:compile
commons-codec:commons-codec:jar:1.2:compile
commons-lang:commons-lang:jar:2.4:compile
commons-logging:commons-logging-api:jar:1.1:compile
javax.ws.rs:jsr311-api:jar:1.0:compile
javax.xml.bind:jaxb-api:jar:2.1:compile
javax.xml.soap:saaj-api:jar:1.3:compile
jaxen:jaxen:jar:1.1.1:compile
org.apache.abdera:abdera-core:jar:0.4.0-incubating:compile
org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating:compile
org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating:compile
org.apache.abdera:abdera-i18n:jar:0.4.0-incubating:compile
org.apache.abdera:abdera-parser:jar:0.4.0-incubating:compile
org.apache.camel:camel-core:jar:2.2-SNAPSHOT:compile
org.apache.camel:camel-spring:jar:2.2-SNAPSHOT:compile
org.apache.cxf:cxf-api:jar:2.2.5:compile
org.apache.cxf:cxf-common-schemas:jar:2.2.5:compile
org.apache.cxf:cxf-common-utilities:jar:2.2.5:compile
org.apache.cxf:cxf-rt-bindings-soap:jar:2.2.5:compile
org.apache.cxf:cxf-rt-bindings-xml:jar:2.2.5:compile
org.apache.cxf:cxf-rt-core:jar:2.2.5:compile
org.apache.cxf:cxf-rt-databinding-aegis:jar:2.2.5:compile
org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2.5:compile
org.apache.cxf:cxf-rt-frontend-jaxrs:jar:2.2.5:compile
org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.2.5:compile
org.apache.cxf:cxf-rt-frontend-simple:jar:2.2.5:compile
org.apache.cxf:cxf-rt-transports-http:jar:2.2.5:compile
org.apache.cxf:cxf-rt-ws-addr:jar:2.2.5:compile
org.apache.cxf:cxf-tools-common:jar:2.2.5:compile
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile
org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile
org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.6:compile
org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0:compile
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2:compile
org.apache.neethi:neethi:jar:2.0.4:compile
org.apache.ws.commons.axiom:axiom-api:jar:1.2.8:compile
org.apache.ws.commons.axiom:axiom-impl:jar:1.2.8:compile
org.apache.ws.commons.schema:XmlSchema:jar:1.4.5:compile
org.apache.xmlbeans:xmlbeans:jar:2.4.0:compile
org.codehaus.jettison:jettison:jar:1.2:compile
org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile
org.fusesource.commonman:commons-management:jar:1.0:compile
org.springframework:spring-aop:jar:2.5.6:compile
org.springframework:spring-beans:jar:2.5.6:compile
org.springframework:spring-context:jar:2.5.6:compile
org.springframework:spring-core:jar:2.5.6:compile
org.springframework:spring-tx:jar:2.5.6:compile
wsdl4j:wsdl4j:jar:1.6.2:compile
xml-resolver:xml-resolver:jar:1.2:compile
Am 20.01.2010 08:22, schrieb Christian Schneider:
> 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.
>
> Greetings
>
> Christian
>
--
Christian Schneider
---
http://www.liquid-reality.de