Kevan, 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: http://cwiki.apache.org/CXF20DOC/configuration.html 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: http://cwiki.apache.org/CXF20DOC/client-http-transport.html 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. Dan > 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 IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
