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
