I've CC:ed you. However, I'd prefer that you respond to the dev list,
only (or cc: me, not reply directly). My mail rules for email
addressed directly to me puts mail in my personal folder. I monitor
Geronimo mail more frequently than personal mail... ;-) Perhaps I
need to tweak my rules a bit...
On Aug 27, 2007, at 10:35 AM, Daniel Kulp wrote:
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.
Thanks much for the info...
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.
Hmm. That's interesting. IIRC, it was a WS-POLICY test that prevented
us from fixing this problem prior to G 2.0.
<snip>
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?
Certainly. One potentially simple option: if the user needs to set a
cxf-specific configuration options in client applications, they'd
need to include Spring jars in their application or declare Spring
dependencies in their deployment plan. This may be an additional
burden on the user, but may not be a big issue given they've started
down a customization route... There's still one issue with this,
approach, however. Will have to dust off the failing tests get to the
bottom of the issue, I guess...
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.
Agreed. Quite likely that we'll need Jarek's knowledge of the
internals of our CXF integration to resolve this issue.
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.
We can certainly consider some automatic trigger.
--kevan
