Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: Kevan Miller <kevan.miller@gmail.com>
Subject: Re: removal of spring dependencies from cxf module
Date: Sat, 25 Aug 2007 17:44:52 -0400
User-Agent: KMail/1.9.7
Cc: dev@geronimo.apache.org
References: <A8E5C383-A0B0-42E3-ACA6-AD636D8BAFFB@gmail.com>
In-Reply-To: <A8E5C383-A0B0-42E3-ACA6-AD636D8BAFFB@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200708251744.53082.dkulp@apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


=46rom my standpoint, it would be greatly preferred if you could find a way=
=20
to leave spring for CXF.   There is definitely a lot of functionality=20
that would be lost if spring is not available.  In particular, if a user=20
want to configure various things like message logging or=20
WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc...,=20
without the spring config, it becomes quite a bit harder.   For very=20
basic usage, spring is optional.   But once you want some=20
customizations, you really need it.

I suppose one option might be to document how to put spring back in if=20
someone needs it.   We could then add more advanced thing to those docs=20
like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS=20
transports, etc....   Kind of an "Advanced WebServices with CXF" type=20
docs.


Dan


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


=2D-=20
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog