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)?
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 >>>
