On Aug 27, 2007, at 11:26 AM, Jeff Genender wrote:
David,
So perhaps I am missing something and you could help clarify this.
You
say "It's by no means obvious to me that treating this as a problem
with
the coding of our classloaders is appropriate." Yet in your 1, 2,
and 3
options, you seem to be saying its basically a problem with
classloading. Is it our classloaders, or is it Spring's (or other)?
Sorry I'm not being clear.
1>> problem with cxf that no amount of changing our classloader code
or configuration will fix. The same problem would occur in tomcat if
you tried to use a spring version incompatible with cxf.
2>> our classloader works as long as you provide spring in the web
app for use by the web app. We could optionally enhance our
classloader so a user would not need spring added to hidden-classes
for the web app.
3>> For ease in making sure the classes from our copy of spring are
normally loaded in the same classloader no matter who is using them,
we might consider have a spring configuration with just the spring
classes in it. This would be more useful if the optional enhancement
suggested in (2) was made.
So I don't see any way the code in our classloaders is wrong. We
might be able to make some things more convenient, and one of those
things would involve a new feature in our classloaders.
I know there's a good chance I'm still writing incomprehensibly, so
don't be shy if this still doesn't make sense :-)
thanks
david jencks
Jeff
David Jencks wrote:
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.
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.
thanks
david jencks
I believe it's the latter. In which case, you're not giving me an
apples-to-apples comparison, IMO.
Well...lets agree to disagree. The bottom line is we are castrating
other projects because we have messed up classloaders. That,
IMNSHO,
has nothing to do with apples-to-apples comparison and we are
creating a
treatment to the problem rather than a panacea.
Do as you may, but call my issue with how we are handling this a
dissenting voice. I am not in agreement with this action.
--kevan
