On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote:
Kevan Miller wrote:
K. Can you explain to me what functionality is being taken away? Dan
said function would be lost, but then listed functionality and
said that
configuring them "becomes quite a bit harder". Nor do I know how this
increased complexity would be who bears the burden for things
becoming
quite a bit harder.
Read Dan's comment/answer. The functionality is the ease of
configuration, etc. For someone who has used Spring extensively, I
think its a huge loss not to be able to leverage it.
I want the client application to be in control of the Spring
version. I
don't want the Geronimo server environment to dictate the version of
Spring used by the client application. At present, we are
dictating the
version of Spring. I think this needs to change. I don't think
this is a
result of our ClassLoader structure.
What are you talking about...this is clearly a classloader
problem. The
fact the client and the server are fighting over whose version of
Spring
is the "right one" points its finger at a classloader issue. The fact
the client has to set the hidden classes attribute on plans clearly
shows this is a classloader problem. Am I missing or not seeing
something here? If so, please point it out...perhaps I'm simply not
getting it. Clashing versions is about as classloader related as
it gets.
I have no real issue with our CXF server module requiring Spring.
I'm less happy if we're requiring that Spring be accessible from a
client application module to configure CXF web services client
capabilities.
I'm way less happy if we require the same Spring instance be
accessible
from the CXF server module and the client application module.
This is
the case, at the moment. I think this needs to be changed.
Why should it be changed? This seems to work with someone using
Tomcat...just not Geronimo.
Does Tomcat embed CXF? Does CXF distribute Tomcat binaries
configured to
provide CXF-based web services? Or does CXF distribute CXF and
associated dependent jars which can be packaged into a WAR and
subsequently deployed into a web container?
CXF can certainly be used in Tomcat. Tomcat doesn't distribute it,
but
it certainly can be used with that web container. It appears the only
project who has this problem is Geronimo :-/
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
