On Monday 01 December 2008 9:04:03 am Steve Cohen wrote: > Speaking from my point of view, and I don't think I'm unique, it might > be a good thing to separate the bundles for CXF-based Clients from those > for CXF-based servers. As a client-side developer, I shouldn't need > and don't want all the flexibility that a server-side WS developer would > need. After all, is client independence of server not practically the > whole point of SOAP? If someone writes a dot-net client for a CXF based > web service, all this java would certainly not be carried over from the > server side. Why should the java client have to carry that burden? > > Jetty, for example, comes to mind. Jetty, as I understand it, is a > server technology that shouldn't be necessary in a client. If they have > some useful utilities, those ought to be packaged separately or else > replaced. Same goes for Spring.
Except both Jetty and Spring are required client side with CXF as well for certain use cases. 1) Jetty is needed client side if you use WS-Addressing or WS-RM with decoupled endpoints/responses. Those specs require the client to bring up and HTTP server that the server will send the responses to. Also, the JAX-WS spec specifically dictates that in your own code, you can do a "Endpoint.publish(...)" in you application (even a standalone application) to startup an endpoint. (combined with WS-Addressing, it allows a callback pattern) 2) Spring is pretty much required (kind of, I suppose you COULD do it all programatically) if you are going to configure anything about the clients. Things like https certs, policies, etc... That all requires the spring configs. > Take these for what they're worth. I am merely a CXF newbie with lots > (too much?) software development experience. I know the devil is in the > details and I don't know the details. There definitely is some stuff in CXF that is "server side or tooling" only that could be pulled from a client install. Things like the javascript generation, the JAXRS stuff right now, probably management, but it's really not much and still have enough there to pass the JAX-WS TCK. Dan > > Benson Margulies wrote: > > Sergey, > > > > What is the maven artifact name of the minimal bundle? And what have > > we got for Confluence advertising thereof? > > > > --benson > > > > > > On Mon, Dec 1, 2008 at 8:29 AM, Sergey Beryozkin > > > > <[EMAIL PROTECTED]> wrote: > >> At least, in trunk/distribution, a similar idea is followed. > >> We have a standard all-inclusive CXF bundle, then we have a minimal one > >> which excludes the tools, rest, xmlbeans and it's only about soap > >> really, etc and we also have a jaxrs bundle... > >> > >> Cheers, Sergey > >> > >>> would it be possible to use different maven profiles to manage > >>> different dependancy sets. e.g. CXF without Rest support / CXF REST > >>> only / CXF without > >>> WS-Security etc... > >>> > >>> On Mon, Dec 1, 2008 at 1:16 PM, Benson Margulies > >>> > >>> <[EMAIL PROTECTED]>wrote: > >>>> Christian, > >>>> > >>>> This perhaps ought to move to dev, but ... > >>>> > >>>> What exactly do you have in mind when you say, 'clean out'? > >>>> > >>>> It might be one of several things. > >>>> > >>>> 1) Divorce CXF entirely from some of its dependencies. > >>>> 2) Document much more carefully what you actually have to have to > >>>> operate in various popular scenarios. > >>>> 3) tweak the Maven dependencies so that a vanilla user doing a vanilla > >>>> build downloads a less stuff? > >>>> > >>>> --benson > >>>> > >>>> > >>>> On Mon, Dec 1, 2008 at 2:13 AM, Christian Schneider > >>>> > >>>> <[EMAIL PROTECTED]> wrote: > >>>>> Hi Steve, > >>>>> > >>>>> I basically think you are right. CXF introduces a lot of dependencies > >>>> > >>>> when > >>>> > >>>>> you add it to your application. For a project manager at the company > >>>>> I > >>>> > >>>> work > >>>> > >>>>> this was almost a reason to throw CXF out and do > >>>>> the parsing by hand. While many maven projects tend to collect > >>>> > >>>> dependencies > >>>> > >>>>> CXF is an especially bad example here. > >>>>> > >>>>> I would vote for making cleaning out dependencies a high priority > >>>>> issue. > >>>>> What do other CXF developers think? > >>>>> > >>>>> BTW. If you have CXF in your project it does not make a lot of sense > >>>>> to > >>>> > >>>> also > >>>> > >>>>> use Axis. I think you should decide on time for your project which > >>>>> webservice stack to use and stick with it. > >>>>> > >>>>> Greetings > >>>>> > >>>>> Christian > >>>>> > >>>>> Steve Cohen schrieb: > >>>>>> My "problem" is more philosophical than anything, and I'm not sure > >>>>>> it's > >>>>>> really a problem. But, consider that by adding a web service > >>>>>> client, a > >>>>>> small new piece of my application's functionality, the WAR file size > >>>>>> has > >>>>>> ballooned in size from 3MB to over 10MB. Additionally, as I look at > >>>>>> the > >>>> > >>>> 33 > >>>> > >>>>>> or so jars it was necessary to add to the war in order to get the > >>>>>> thing > >>>> > >>>> to > >>>> > >>>>>> run (and I manually hacked 14 out of the dependencies generated by > >>>>>> Maven > >>>>>> which I found NOT to be needed), I can't say I know what most of > >>>>>> them > >>>> > >>>> do. > >>>> > >>>>>> Why, for example, was it necessary to include pieces of the Spring > >>>>>> framework, even though my application doesn't use that framework? > >>>>>> What, > >>>> > >>>> for > >>>> > >>>>>> Pete's sake, is Neethi, and why was it necessary to add it? Quite a > >>>>>> lot > >>>> > >>>> of > >>>> > >>>>>> stuff for the "simple" task of marshalling and unmarshalling data > >>>>>> into SOAP-XML packets and sending them across the wire. From their > >>>>>> names, it > >>>>>> looks as though some of them repeat functionality that is available > >>>>>> in > >>>> > >>>> other > >>>> > >>>>>> jars - but who has time to investigate? I also have a little > >>>>>> nagging > >>>> > >>>> fear > >>>> > >>>>>> that down the road a few weeks, when I have to add my NEXT web > >>>>>> service client to this app (and this one uses AXIS) I will end up > >>>>>> adding another > >>>>>> bunch of jars, some of which may conflict with the ones just added. > >>>>>> In other words I feel that I've lost control of my application. > >>>>>> > >>>>>> Prior to this, I understood my dependencies. I understand that > >>>>>> there's > >>>> > >>>> a > >>>> > >>>>>> tradeoff here. In return for letting go of control of my > >>>>>> dependencies, > >>>> > >>>> I > >>>> > >>>>>> have a potentially much simpler and more automated build process - > >>>>>> and I > >>>>>> know that's a good thing - especially when and if I convert the > >>>> > >>>> project's > >>>> > >>>>>> entire build process to Maven. And speaking of CXF in particular, I > >>>> > >>>> like > >>>> > >>>>>> that the client code I need to write is not particularly ugly, as it > >>>>>> is > >>>> > >>>> with > >>>> > >>>>>> some other SOAP platforms (AXIS - grr grr). But I continue to > >>>>>> wonder whether it isn't a problem that Maven encourages these chains > >>>>>> of dependencies that grow geometrically without appropriate > >>>>>> consideration > >>>> > >>>> to > >>>> > >>>>>> developer understanding being given. For the sake of developer > >>>>>> understanding, would it perhaps be a good thing if pom.xml > >>>>>> dependency elements had a required <comment> element that the > >>>>>> composer of a POM > >>>> > >>>> would > >>>> > >>>>>> have to think about before issuing a POM to the world? Or maybe a > >>>>>> newer > >>>>>> version of CXF will pare the dependencies down to what is truly > >>>>>> needed > >>>> > >>>> to > >>>> > >>>>>> run client-side and server-side apps. > >>>>>> > >>>>>> <end of rant> > >>>>> > >>>>> -- > >>>>> > >>>>> Christian Schneider > >>>>> --- > >>>>> http://www.liquid-reality.de -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
