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 Sat, 25 Aug 2007 21:44:52 GMT

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.

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 


On Saturday 25 August 2007, Kevan Miller wrote:
> On Aug 25, 2007, at 10:53 AM, Jeff Genender wrote:
> > Kevan Miller wrote:
> >> On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote:
> >>> Kevan,
> >>>
> >>> IIU the reason you are asking, removal of the Spring dependencies
> >>> from
> >>> CXF would appear to be a band aid and temporary fix to the real
> >>> issue.
> >>> Is this about the Spring versioning and different versions getting
> >>> loaded? (If not then never mind)
> >>
> >> I wouldn't characterize this as a band-aid. And I doubt that I
> >> would advocate a different approach to solving this problem in a
> >> 2.0.x release.
> >
> > Umm...why wouldn't you characterize this as a band aid?  The
> > problem is
> > our class loaders.  You still have this problem if someone
> > integrates something that uses Spring...right?
> Sorry. I must not be explaining things very well... At present our
> CXF integration requires access to the same instance of Spring in
> both the cxf module as well as the client application module. This
> means that the client application module cannot have a unique
> instance of Spring and work with CXF -- this must be fixed regardless
> of our ClassLoader structure.  I'm pretty sure that you would agree
> with this?
> In addition, I would not advocate a significant change to our
> ClassLoader behavior in a 2.0.x release (although I may be about to
> advocate for a change to our EAR classloading structure -- more on
> this in a different thread). At best this type of change would belong
> in a 2.x release, IMHO, since client applications are likely to be
> reliant on our current classloading behavior.
> >> FYI, at present, cxf-based web services client code requires
> >> access to
> >> Spring classes from the application's ClassLoader. So, even if you
> >> wanted to completely isolate the application ClassLoader from
> >> system ClassLoaders, this must be changed. I probably could have
> >> narrowed my request a bit by saying can we just fix this web
> >> services client code dependency -- better, I think to remove the
> >> spring dependency all together from our cxf module.
> >
> > So what would happen if I integrate another 3rd party component that
> > uses Spring...say...Terracotta DSO? Or...ServiceMix?  What happens
> > then?
> At present, these components can be integrated into Geronimo.
> Depending on their module-level dependencies, there might be some
> intra-server spring versioning problems. I assume that we would
> resolve those.
> Currently, client applications that want to run their own Spring
> instance would need the following in their deployment plan
> environment:
>      <hidden-classes>
>        <filter>org.springframework.</filter>
>        <filter>META-INF/spring</filter>
>      </hidden-classes>
> Until the above CXF-Spring requirement is fixed, this filtering may
> cause problems in some client applications using web services.
> Geronimo used to hide these Spring classes/resources from client
> applications automatically. However, this automatic hiding of Spring
> was removed because of the CXF-Spring issue that is currently being
> discussed.
> So, IMO:
> 1. We need to break the requirement for the sharing of a single
> instance of Spring betweeen the cxf module and a client application
> module. This can be via removal of the CXF Spring dependency all
> together, or by some alternate means (e.g. reworking of the web
> services client code)... Sorry to be vague, here. I'm not currently
> familiar with the details of the client code...
> 2. Once 1 is addressed, reinstate the automatic filtering of Spring
> classes/resources.
> 3. For a 2.x release, discuss alternate/preferred behavior.
> --kevan

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

View raw message