geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: removal of spring dependencies from cxf module
Date Mon, 27 Aug 2007 14:35:59 GMT


On Monday 27 August 2007, Kevan Miller wrote:
> On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:
> > From my standpoint, it would be greatly preferred if you could find
> > a way
> > to leave spring for CXF.   There is definitely a lot of
> > functionality that would be lost if spring is not available.  In
> > particular, if a user
> > want to configure various things like message logging or
> > WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking,
> > etc..., without the spring config, it becomes quite a bit harder.  
> > For very basic usage, spring is optional.   But once you want some
> > customizations, you really need it.
> OK. First I've heard of loss of functionality... Is there loss of
> functionality? Or things become harder without Spring?

For the most part, it's "things become much harder," mostly because we 
really only document the Spring way of doing things.  Doing 
things "non-spring" requires a bunch of casting of JAX-WS things into 
proprietary things, calling semi-hidden API's, etc...   The spring way 
is very clean, documented, etc...   See:
particularly the sub-pages listed at the bottom.

One area that definitely doesn't work without spring is the ws-policy 
stuff.   Turning on policy requires some spring stuff right now.   I 
think that's logged as a bug.

> If things 
> become harder, an important question is who pays the price? The
> embedder (i.e. us)? Or the user?

Definitely the user IF they need something outside the normal "soap/http" 
cases.   For just straight JAX-WS TCK compliance stuff, it doesn't 
matter one way or the other. 

One example:  lets say your using a JAX-WS client in your application 
that needs to talk to an OLD .NET service.   The older .NET stuff 
sometimes doesn't like HTTP chunking.    There are docs at:
to describe how to configure the client to not use chunking.   There's 
also a bunch of things there for configuring the SSL connections, etc...

> I have no real issue with our CXF server module requiring Spring.
> I'm less happy if we're requiring that Spring be accessible from a
> client application module to configure CXF web services client
> capabilities.

Can it be optional?   Set some filtering thing so if they want/need the 
spring stuff, they can get it?

That all said, I DON'T know if Geronimo current exposes a spring context 
or anything that would currently allow any of that to work.   My gut 
feeling says no, but I'm not really sure.     It's quite possible that 
it doesn't work in Geronimo right now anyway.   It's probably that the 
spring stuff in Geronimo is on a more "global" basis and wouldn't allow 
per-application configuration anyway.   Probably Jarek would need to 
weigh in how that currently works as I don't really know.

Ideally to me, if the app has a META-INF/cxf.xml or similar (some other 
key or something), the spring stuff would allow configuring of a bunch 
of the things specific for that application.


> I'm way less happy if we require the same Spring instance be
> accessible from the CXF server module and the client application
> module. This is the case, at the moment. I think this needs to be
> changed.
> > I suppose one option might be to document how to put spring back in
> > if someone needs it.   We could then add more advanced thing to
> > those docs
> > like where to get the additional jars for WS-RM/WS-A/WS-Security,
> > JMS transports, etc....   Kind of an "Advanced WebServices with CXF"
> > type docs.
> Can you point me to documentation on how a user configures this
> functionality currently?
> --kevan

J. Daniel Kulp
Principal Engineer
P: 781-902-8727    C: 508-380-7194

View raw message