Re: removal of spring dependencies from cxf module
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
Re: removal of spring dependencies from cxf module
On Sep 11, 2007, at 5:37 PM, Jarek Gawor wrote: 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. Cool. Thanks Jarek! I think this will fix the Spring problems, we've seen to date with Jetty/CXF. There are still some things we can do, in addition to this: 1) Create a separate Spring module. The CXF module would be dependent upon this module. Other system modules could also be dependent upon this Spring module. Optionally, client applications could have a dependency on this module. 2) Currently, our ClassLoaders can only filter classes from their parents. Would be cleaner if we allowed the CXF module to filter Spring classes from its children. 3) Would be good to upgrade our Spring version. There used to be a problem with 2.0.5+ versions of Spring and XBean. I think I've fixed that in XBean. Possible that CXF has an issue with newer versions of Spring. --kevan
Re: removal of spring dependencies from cxf module
On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote: From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. OK. First I've heard of loss of functionality... Is there loss of functionality? Or things become harder without Spring? If things become harder, an important question is who pays the price? The embedder (i.e. us)? Or the user? 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. I suppose one option might be to document how to put spring back in if someone needs it. We could then add more advanced thing to those docs like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS transports, etc Kind of an Advanced WebServices with CXF type docs. Can you point me to documentation on how a user configures this functionality currently? --kevan
Re: removal of spring dependencies from cxf module
Kevan Miller wrote: On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote: From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. OK. First I've heard of loss of functionality... Is there loss of functionality? Or things become harder without Spring? If things become harder, an important question is who pays the price? The embedder (i.e. us)? Or the user? I have to agree with Dan on this. This is clearly our problem. It's Geronimo's classloaders that are causing the issue. We are taking away functionality at the expense of our inability to handle Spring. 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. I suppose one option might be to document how to put spring back in if someone needs it. We could then add more advanced thing to those docs like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS transports, etc Kind of an Advanced WebServices with CXF type docs. Can you point me to documentation on how a user configures this functionality currently? --kevan
Re: removal of spring dependencies from cxf module
Kevan, On Monday 27 August 2007, Kevan Miller wrote: On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote: From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. OK. First I've heard of loss of functionality... Is there loss of functionality? Or things become harder without Spring? For the most part, it's things become much harder, mostly because we really only document the Spring way of doing things. Doing things non-spring requires a bunch of casting of JAX-WS things into proprietary things, calling semi-hidden API's, etc... The spring way is very clean, documented, etc... See: http://cwiki.apache.org/CXF20DOC/configuration.html particularly the sub-pages listed at the bottom. One area that definitely doesn't work without spring is the ws-policy stuff. Turning on policy requires some spring stuff right now. I think that's logged as a bug. If things become harder, an important question is who pays the price? The embedder (i.e. us)? Or the user? Definitely the user IF they need something outside the normal soap/http cases. For just straight JAX-WS TCK compliance stuff, it doesn't matter one way or the other. One example: lets say your using a JAX-WS client in your application that needs to talk to an OLD .NET service. The older .NET stuff sometimes doesn't like HTTP chunking.There are docs at: http://cwiki.apache.org/CXF20DOC/client-http-transport.html to describe how to configure the client to not use chunking. There's also a bunch of things there for configuring the SSL connections, etc... 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. Can it be optional? Set some filtering thing so if they want/need the spring stuff, they can get it? That all said, I DON'T know if Geronimo current exposes a spring context or anything that would currently allow any of that to work. My gut feeling says no, but I'm not really sure. It's quite possible that it doesn't work in Geronimo right now anyway. It's probably that the spring stuff in Geronimo is on a more global basis and wouldn't allow per-application configuration anyway. Probably Jarek would need to weigh in how that currently works as I don't really know. Ideally to me, if the app has a META-INF/cxf.xml or similar (some other key or something), the spring stuff would allow configuring of a bunch of the things specific for that application. Dan 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. I suppose one option might be to document how to put spring back in if someone needs it. We could then add more advanced thing to those docs like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS transports, etc Kind of an Advanced WebServices with CXF type docs. Can you point me to documentation on how a user configures this functionality currently? --kevan -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: removal of spring dependencies from cxf module
On Aug 27, 2007, at 10:11 AM, Jeff Genender wrote: Kevan Miller wrote: On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote: From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. OK. First I've heard of loss of functionality... Is there loss of functionality? Or things become harder without Spring? If things become harder, an important question is who pays the price? The embedder (i.e. us)? Or the user? I have to agree with Dan on this. This is clearly our problem. It's Geronimo's classloaders that are causing the issue. We are taking away functionality at the expense of our inability to handle Spring. 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. 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. 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? I believe it's the latter. In which case, you're not giving me an apples-to-apples comparison, IMO. --kevan
Re: removal of spring dependencies from cxf module
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 :-/ 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
Re: removal of spring dependencies from cxf module
I've CC:ed you. However, I'd prefer that you respond to the dev list, only (or cc: me, not reply directly). My mail rules for email addressed directly to me puts mail in my personal folder. I monitor Geronimo mail more frequently than personal mail... ;-) Perhaps I need to tweak my rules a bit... On Aug 27, 2007, at 10:35 AM, Daniel Kulp wrote: Kevan, On Monday 27 August 2007, Kevan Miller wrote: On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote: From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. OK. First I've heard of loss of functionality... Is there loss of functionality? Or things become harder without Spring? For the most part, it's things become much harder, mostly because we really only document the Spring way of doing things. Doing things non-spring requires a bunch of casting of JAX-WS things into proprietary things, calling semi-hidden API's, etc... The spring way is very clean, documented, etc... See: http://cwiki.apache.org/CXF20DOC/configuration.html particularly the sub-pages listed at the bottom. Thanks much for the info... One area that definitely doesn't work without spring is the ws-policy stuff. Turning on policy requires some spring stuff right now. I think that's logged as a bug. Hmm. That's interesting. IIRC, it was a WS-POLICY test that prevented us from fixing this problem prior to G 2.0. snip 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. Can it be optional? Set some filtering thing so if they want/need the spring stuff, they can get it? Certainly. One potentially simple option: if the user needs to set a cxf-specific configuration options in client applications, they'd need to include Spring jars in their application or declare Spring dependencies in their deployment plan. This may be an additional burden on the user, but may not be a big issue given they've started down a customization route... There's still one issue with this, approach, however. Will have to dust off the failing tests get to the bottom of the issue, I guess... That all said, I DON'T know if Geronimo current exposes a spring context or anything that would currently allow any of that to work. My gut feeling says no, but I'm not really sure. It's quite possible that it doesn't work in Geronimo right now anyway. It's probably that the spring stuff in Geronimo is on a more global basis and wouldn't allow per-application configuration anyway. Probably Jarek would need to weigh in how that currently works as I don't really know. Agreed. Quite likely that we'll need Jarek's knowledge of the internals of our CXF integration to resolve this issue. Ideally to me, if the app has a META-INF/cxf.xml or similar (some other key or something), the spring stuff would allow configuring of a bunch of the things specific for that application. We can certainly consider some automatic trigger. --kevan
Re: removal of spring dependencies from cxf module
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
Re: removal of spring dependencies from cxf module
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
Re: removal of spring dependencies from cxf module
On Aug 27, 2007, at 2:16 PM, David Jencks wrote: On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote: Kevan Miller wrote: snip 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. Mostly correct, I think. IIRC, this worked except for one measly WS- Policy test case in testsuite. This test failed with Spring hidden- classes. I then attempted to get a unique instance of Spring running in the application classloader and the test still failed. It would only work if Spring was loaded from the parent ClassLoader. Given what I've learned from Dan, I'm starting to think that this was likely a configuration problem. If we were not able to read a server- wide CXF configuration (because it was hidden), then the client application might not have had the expected configuration -- thus the test failure. This is pure speculation, at the moment... 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. Hmm. Maybe. Definitely worth investigating. --kevan
Re: removal of spring dependencies from cxf module
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
Re: removal of spring dependencies from cxf module
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
Re: removal of spring dependencies from cxf module
On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote: Kevan, IIU the reason you are asking, removal of the Spring dependencies from CXF would appear to be a band aid and temporary fix to the real issue. Is this about the Spring versioning and different versions getting loaded? (If not then never mind) I wouldn't characterize this as a band-aid. And I doubt that I would advocate a different approach to solving this problem in a 2.0.x release. FYI, at present, cxf-based web services client code requires access to Spring classes from the application's ClassLoader. So, even if you wanted to completely isolate the application ClassLoader from system ClassLoaders, this must be changed. I probably could have narrowed my request a bit by saying can we just fix this web services client code dependency -- better, I think to remove the spring dependency all together from our cxf module. --kevan
Re: removal of spring dependencies from cxf module
Kevan Miller wrote: On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote: Kevan, IIU the reason you are asking, removal of the Spring dependencies from CXF would appear to be a band aid and temporary fix to the real issue. Is this about the Spring versioning and different versions getting loaded? (If not then never mind) I wouldn't characterize this as a band-aid. And I doubt that I would advocate a different approach to solving this problem in a 2.0.x release. Umm...why wouldn't you characterize this as a band aid? The problem is our class loaders. You still have this problem if someone integrates something that uses Spring...right? FYI, at present, cxf-based web services client code requires access to Spring classes from the application's ClassLoader. So, even if you wanted to completely isolate the application ClassLoader from system ClassLoaders, this must be changed. I probably could have narrowed my request a bit by saying can we just fix this web services client code dependency -- better, I think to remove the spring dependency all together from our cxf module. So what would happen if I integrate another 3rd party component that uses Spring...say...Terracotta DSO? Or...ServiceMix? What happens then? --kevan
Re: removal of spring dependencies from cxf module
On Aug 25, 2007, at 10:53 AM, Jeff Genender wrote: Kevan Miller wrote: On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote: Kevan, IIU the reason you are asking, removal of the Spring dependencies from CXF would appear to be a band aid and temporary fix to the real issue. Is this about the Spring versioning and different versions getting loaded? (If not then never mind) I wouldn't characterize this as a band-aid. And I doubt that I would advocate a different approach to solving this problem in a 2.0.x release. Umm...why wouldn't you characterize this as a band aid? The problem is our class loaders. You still have this problem if someone integrates something that uses Spring...right? Sorry. I must not be explaining things very well... At present our CXF integration requires access to the same instance of Spring in both the cxf module as well as the client application module. This means that the client application module cannot have a unique instance of Spring and work with CXF -- this must be fixed regardless of our ClassLoader structure. I'm pretty sure that you would agree with this? In addition, I would not advocate a significant change to our ClassLoader behavior in a 2.0.x release (although I may be about to advocate for a change to our EAR classloading structure -- more on this in a different thread). At best this type of change would belong in a 2.x release, IMHO, since client applications are likely to be reliant on our current classloading behavior. FYI, at present, cxf-based web services client code requires access to Spring classes from the application's ClassLoader. So, even if you wanted to completely isolate the application ClassLoader from system ClassLoaders, this must be changed. I probably could have narrowed my request a bit by saying can we just fix this web services client code dependency -- better, I think to remove the spring dependency all together from our cxf module. So what would happen if I integrate another 3rd party component that uses Spring...say...Terracotta DSO? Or...ServiceMix? What happens then? At present, these components can be integrated into Geronimo. Depending on their module-level dependencies, there might be some intra-server spring versioning problems. I assume that we would resolve those. Currently, client applications that want to run their own Spring instance would need the following in their deployment plan environment: hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /hidden-classes Until the above CXF-Spring requirement is fixed, this filtering may cause problems in some client applications using web services. Geronimo used to hide these Spring classes/resources from client applications automatically. However, this automatic hiding of Spring was removed because of the CXF-Spring issue that is currently being discussed. So, IMO: 1. We need to break the requirement for the sharing of a single instance of Spring betweeen the cxf module and a client application module. This can be via removal of the CXF Spring dependency all together, or by some alternate means (e.g. reworking of the web services client code)... Sorry to be vague, here. I'm not currently familiar with the details of the client code... 2. Once 1 is addressed, reinstate the automatic filtering of Spring classes/resources. 3. For a 2.x release, discuss alternate/preferred behavior. --kevan
Re: removal of spring dependencies from cxf module
From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. I suppose one option might be to document how to put spring back in if someone needs it. We could then add more advanced thing to those docs like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS transports, etc Kind of an Advanced WebServices with CXF type docs. Dan On Saturday 25 August 2007, Kevan Miller wrote: On Aug 25, 2007, at 10:53 AM, Jeff Genender wrote: Kevan Miller wrote: On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote: Kevan, IIU the reason you are asking, removal of the Spring dependencies from CXF would appear to be a band aid and temporary fix to the real issue. Is this about the Spring versioning and different versions getting loaded? (If not then never mind) I wouldn't characterize this as a band-aid. And I doubt that I would advocate a different approach to solving this problem in a 2.0.x release. Umm...why wouldn't you characterize this as a band aid? The problem is our class loaders. You still have this problem if someone integrates something that uses Spring...right? Sorry. I must not be explaining things very well... At present our CXF integration requires access to the same instance of Spring in both the cxf module as well as the client application module. This means that the client application module cannot have a unique instance of Spring and work with CXF -- this must be fixed regardless of our ClassLoader structure. I'm pretty sure that you would agree with this? In addition, I would not advocate a significant change to our ClassLoader behavior in a 2.0.x release (although I may be about to advocate for a change to our EAR classloading structure -- more on this in a different thread). At best this type of change would belong in a 2.x release, IMHO, since client applications are likely to be reliant on our current classloading behavior. FYI, at present, cxf-based web services client code requires access to Spring classes from the application's ClassLoader. So, even if you wanted to completely isolate the application ClassLoader from system ClassLoaders, this must be changed. I probably could have narrowed my request a bit by saying can we just fix this web services client code dependency -- better, I think to remove the spring dependency all together from our cxf module. So what would happen if I integrate another 3rd party component that uses Spring...say...Terracotta DSO? Or...ServiceMix? What happens then? At present, these components can be integrated into Geronimo. Depending on their module-level dependencies, there might be some intra-server spring versioning problems. I assume that we would resolve those. Currently, client applications that want to run their own Spring instance would need the following in their deployment plan environment: hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /hidden-classes Until the above CXF-Spring requirement is fixed, this filtering may cause problems in some client applications using web services. Geronimo used to hide these Spring classes/resources from client applications automatically. However, this automatic hiding of Spring was removed because of the CXF-Spring issue that is currently being discussed. So, IMO: 1. We need to break the requirement for the sharing of a single instance of Spring betweeen the cxf module and a client application module. This can be via removal of the CXF Spring dependency all together, or by some alternate means (e.g. reworking of the web services client code)... Sorry to be vague, here. I'm not currently familiar with the details of the client code... 2. Once 1 is addressed, reinstate the automatic filtering of Spring classes/resources. 3. For a 2.x release, discuss alternate/preferred behavior. --kevan -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: removal of spring dependencies from cxf module
Kevan, IIU the reason you are asking, removal of the Spring dependencies from CXF would appear to be a band aid and temporary fix to the real issue. Is this about the Spring versioning and different versions getting loaded? (If not then never mind) Jeff Kevan Miller wrote: We've run into multiple issues caused by the dependency of our cxf module on Spring. Jarek, you've mentioned that it's possible to switch from Spring-based configuration of CXF to, hmm, some other form of configuration (xml/programmatic?). How hard would this be? Could we get this done for a 2.0.2 release? --kevan
Re: removal of spring dependencies from cxf module
Kevan, I'm out on vacation all next week but I was planning to take a look at this issue right after I get back. My intention was to get it done for the 2.0.2 release. Jarek j On 8/24/07, Kevan Miller [EMAIL PROTECTED] wrote: We've run into multiple issues caused by the dependency of our cxf module on Spring. Jarek, you've mentioned that it's possible to switch from Spring- based configuration of CXF to, hmm, some other form of configuration (xml/programmatic?). How hard would this be? Could we get this done for a 2.0.2 release? --kevan
Re: removal of spring dependencies from cxf module
On Aug 24, 2007, at 5:57 PM, Jarek Gawor wrote: Kevan, I'm out on vacation all next week but I was planning to take a look at this issue right after I get back. My intention was to get it done for the 2.0.2 release. Cool. That'd be great! --kevan
