You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2007/08/24 23:30:27 UTC
removal of spring dependencies from cxf module
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Daniel Kulp <dk...@apache.org>.
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-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: removal of spring dependencies from cxf module
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Jarek Gawor <jg...@gmail.com>.
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 <da...@yahoo.com> 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
Posted by Jeff Genender <jg...@apache.org>.
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
Posted by David Jencks <da...@yahoo.com>.
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
Posted by Jeff Genender <jg...@apache.org>.
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
Posted by David Jencks <da...@yahoo.com>.
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
Posted by Jeff Genender <jg...@apache.org>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Jeff Genender <jg...@apache.org>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Daniel Kulp <dk...@apache.org>.
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>
> <filter>org.springframework.</filter>
> <filter>META-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-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: removal of spring dependencies from cxf module
Posted by Kevan Miller <ke...@gmail.com>.
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>
<filter>org.springframework.</filter>
<filter>META-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
Posted by Jeff Genender <jg...@apache.org>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Posted by Jeff Genender <jg...@apache.org>.
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
Posted by Kevan Miller <ke...@gmail.com>.
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
Re: removal of spring dependencies from cxf module
Posted by Jarek Gawor <jg...@gmail.com>.
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 <ke...@gmail.com> 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
>