On Aug 27, 2007, at 2:16 PM, David Jencks wrote:
On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote:
Kevan Miller wrote:
<snip>
Cool down a minute and think about this. What happens in tomcat if
you want to use cxf + an incompatible version of spring in your
app? You bundle cxf + springA + springB into your web-app and then
what happens?
IMO we are talking about trying to get geronimo to generically
solve a problem that tomcat forces its users to deal with on an per-
app basis.
It's by no means obvious to me that treating this as a problem with
the coding of our classloaders is appropriate. Here are some
possibilities I can think of off the top of my head:
1. cxf generates some code for each web service client/service
that directly use spring classes. In this case there is AFAIK no
way for an app to use a different spring version since these
generated classes are going to be loaded in the application
classloader and they need access to cxf's copy of spring classes.
If this is what is going on I hope it's possible for cxf to stop
doing this.
2. If putting spring in the apps hidden-classes works and allows
the app to use a different spring version, then evidently (1) isn't
a problem. In this case if we automatically add spring to hidden-
classes of every app we would be preventing all apps from using our
copy of spring which seems undesirable to me. hidden-classes
currently means "don't import these classes from parents". We
could look into also having a "don't export these classes to
children" filter in our classloader.
Mostly correct, I think. IIRC, this worked except for one measly WS-
Policy test case in testsuite. This test failed with Spring hidden-
classes. I then attempted to get a unique instance of Spring running
in the application classloader and the test still failed. It would
only work if Spring was loaded from the parent ClassLoader. Given
what I've learned from Dan, I'm starting to think that this was
likely a configuration problem. If we were not able to read a server-
wide CXF configuration (because it was hidden), then the client
application might not have had the expected configuration -- thus the
test failure. This is pure speculation, at the moment...
3. With just the "don't export" filter proposed in (2), people
adding the spring jars to their dependency list would be getting
spring loaded in a different classloader for their app and for
cxf. This might not be desirable. We could make a spring
configuration to provide a single classloader to load spring in
that cxf and apps could depend on.
Hmm. Maybe. Definitely worth investigating.
--kevan
