I think we have an acceptable solution for this whole CXF/Spring issue. First, CXF will continue to be configured with Spring as before. Second, all web applications will now get an automatic <hidden-classes> filtering for Spring classes and resources. That should enable applications to have their own versions of Spring and reduce conflicts with Geronimo's version. The key to this solution was ensuring that CXF was initialized/configured with the CXF module classloader and not the application classloader. If the application classloader was used, and it had Spring filtering enabled, the Spring configuration files were filtered away. That caused incomplete configuration of CXF and failures later on. When CXF module classloader is used, the right Spring configuration files are discovered and things work nicely. Of course, now if the application has its own CXF configuration files they will be ignored. So this solution is not perfect but hopefully should be good enough for 2.0.2.
I committed the changes to trunk and branches/2.0 if people want to review. Jarek On 8/27/07, David Jencks <[EMAIL PROTECTED]> 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 > >>>> > >
