No...that made much more sense to me ;-) I think convenience is the way to go. I am following you now.
Thanks, Jeff David Jencks wrote: > > 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 >>>>>
