geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: removal of spring dependencies from cxf module
Date Mon, 27 Aug 2007 17:14:18 GMT
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

Mime
View raw message