You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2007/09/14 20:56:03 UTC
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Ugh... I had a feeling that this filtering will cause problems for
someone. Anyway, in general I think moving the hidden-classes filter
to the CXF deployer is a better solution (to keep it all together and
assuming it has the same effect as when specified in the web container
deployer). But, in this case I don't think this will work right still.
First, in CXF there are two key deployers. One that handles deployment
of web services and another one that handles service references (it's
a naming builder). Both will need the hidden-classes filter (the patch
only updates the web service deployer). However, because the way
currently the naming builders work in Geronimo, the environment of
naming builders is always merged no matter if the application has a
service reference or not (or whatever the naming builder is looking
for). So at the end, even if we moved the hidden-classes filter to the
CXF deployers, the filter will still be injected. So we might need to
fix how the naming builders work or find a better way to deal with
Spring filtering. I'm not sure what's the right solution here.
Jarek
On 9/14/07, Paul McMahan <pa...@gmail.com> wrote:
> Jarek, This commit is causing some problems for the new admin
> console plugin because it needs to inherit the spring classes from
> its parent component (pluto-support). This situation is the inverse
> of the original problem we were hoping to solve where a web-app does
> *not* want to inherit the spring classes :-)
>
> Could we move the springframework hidden-classes filter from the
> tomcat and jetty deployers to the cxf-deployer? Doing that
> alleviated the problem for me since the console webapp doesn't
> contain any web services, and therefore won't inherit these
> filters. To me it seems more correct to apply the filters via cxf-
> deployer since cxf's dependency on spring was really the issue. Here
> is a patch showing what I changed. If it works OK for you then
> please go ahead and commit or let me know and I will do it.
>
> Index: configs/tomcat6-deployer/src/main/plan/plan.xml
> ===================================================================
> --- configs/tomcat6-deployer/src/main/plan/plan.xml (revision
> 575651)
> +++ configs/tomcat6-deployer/src/main/plan/plan.xml (working copy)
> @@ -70,10 +70,7 @@
> <type>car</type>
> </dependency>
> </dependencies>
> - <hidden-classes>
> - <filter>org.springframework.</filter>
> - <filter>META-INF/spring</filter>
> - </hidden-classes>
> + <hidden-classes/>
> <non-overridable-classes>
> <filter>java.</filter>
> <filter>javax.</filter>
> Index: configs/tomcat6-deployer/src/plan/plan.xml
> ===================================================================
> --- configs/tomcat6-deployer/src/plan/plan.xml (revision 575651)
> +++ configs/tomcat6-deployer/src/plan/plan.xml (working copy)
> @@ -70,10 +70,7 @@
> <type>car</type>
> </dependency>
> </dependencies>
> - <hidden-classes>
> - <filter>org.springframework.</filter>
> - <filter>META-INF/spring</filter>
> - </hidden-classes>
> + <hidden-classes/>
> <non-overridable-classes>
> <filter>java.</filter>
> <filter>javax.</filter>
> Index: configs/jetty6-deployer/src/main/plan/plan.xml
> ===================================================================
> --- configs/jetty6-deployer/src/main/plan/plan.xml (revision
> 575651)
> +++ configs/jetty6-deployer/src/main/plan/plan.xml (working copy)
> @@ -170,10 +170,7 @@
> <type>car</type>
> </dependency>
> </dependencies>
> - <hidden-classes>
> - <filter>org.springframework.</filter>
> - <filter>META-INF/spring</filter>
> - </hidden-classes>
> + <hidden-classes/>
> <non-overridable-classes>
> <filter>java.</filter>
> <filter>javax.</filter>
> @@ -213,4 +210,4 @@
> <gbean name="POJOTemplate"
> class="org.apache.geronimo.jetty6.JettyPOJOWebServiceHolder">
> <attribute name="servletName">dummy</attribute>
> </gbean>
> -</module>
> \ No newline at end of file
> +</module>
> Index: configs/jetty6-deployer/src/plan/plan.xml
> ===================================================================
> --- configs/jetty6-deployer/src/plan/plan.xml (revision 575651)
> +++ configs/jetty6-deployer/src/plan/plan.xml (working copy)
> @@ -130,10 +130,7 @@
> <type>car</type>
> </dependency>
> </dependencies>
> - <hidden-classes>
> - <filter>org.springframework.</filter>
> - <filter>META-INF/spring</filter>
> - </hidden-classes>
> + <hidden-classes/>
> <non-overridable-classes>
> <filter>java.</filter>
> <filter>javax.</filter>
> Index: configs/cxf-deployer/src/main/plan/plan.xml
> ===================================================================
> --- configs/cxf-deployer/src/main/plan/plan.xml (revision 575651)
> +++ configs/cxf-deployer/src/main/plan/plan.xml (working copy)
> @@ -30,6 +30,10 @@
> <type>car</type>
> </dependency>
> </dependencies>
> + <hidden-classes>
> + <filter>org.springframework.</filter>
> + <filter>META-INF/spring</filter>
> + </hidden-classes>
> </environment>
> </xml-attribute>
> </gbean>
>
>
>
>
>
>
>
> On Sep 11, 2007, at 5:21 PM, gawor@apache.org wrote:
>
> > Author: gawor
> > Date: Tue Sep 11 14:21:15 2007
> > New Revision: 574694
> >
> > URL: http://svn.apache.org/viewvc?rev=574694&view=rev
> > Log:
> > fix the cxf/spring issues by hiding the spring classes and
> > resources from the application classloader and by making cxf to use
> > cxf/car module classloader to load spring resources instead of the
> > application classloader
> >
> > Modified:
> > geronimo/server/trunk/configs/jetty6-deployer/src/main/plan/
> > plan.xml
> > geronimo/server/trunk/configs/jetty6-deployer/src/plan/plan.xml
> > geronimo/server/trunk/configs/tomcat6-deployer/src/main/plan/
> > plan.xml
> > geronimo/server/trunk/configs/tomcat6-deployer/src/plan/plan.xml
> > geronimo/server/trunk/modules/geronimo-cxf/src/main/java/org/
> > apache/geronimo/cxf/CXFWebServiceContainer.java
> > geronimo/server/trunk/modules/geronimo-cxf/src/main/java/org/
> > apache/geronimo/cxf/client/CXFServiceReference.java
> >
> > Modified: geronimo/server/trunk/configs/jetty6-deployer/src/main/
> > plan/plan.xml
> > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
> > jetty6-deployer/src/main/plan/plan.xml?
> > rev=574694&r1=574693&r2=574694&view=diff
> > ======================================================================
> > ========
> > --- geronimo/server/trunk/configs/jetty6-deployer/src/main/plan/
> > plan.xml (original)
> > +++ geronimo/server/trunk/configs/jetty6-deployer/src/main/plan/
> > plan.xml Tue Sep 11 14:21:15 2007
> > @@ -170,7 +170,10 @@
> > <type>car</type>
> > </dependency>
> > </dependencies>
> > - <hidden-classes/>
> > + <hidden-classes>
> > + <filter>org.springframework.</filter>
> > + <filter>META-INF/spring</filter>
> > + </hidden-classes>
> > <non-overridable-classes>
> > <filter>java.</filter>
> > <filter>javax.</filter>
> >
> > Modified: geronimo/server/trunk/configs/jetty6-deployer/src/plan/
> > plan.xml
> > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
> > jetty6-deployer/src/plan/plan.xml?
> > rev=574694&r1=574693&r2=574694&view=diff
> > ======================================================================
> > ========
> > --- geronimo/server/trunk/configs/jetty6-deployer/src/plan/plan.xml
> > (original)
> > +++ geronimo/server/trunk/configs/jetty6-deployer/src/plan/plan.xml
> > Tue Sep 11 14:21:15 2007
> > @@ -130,7 +130,10 @@
> > <type>car</type>
> > </dependency>
> > </dependencies>
> > - <hidden-classes/>
> > + <hidden-classes>
> > + <filter>org.springframework.</filter>
> > + <filter>META-INF/spring</filter>
> > + </hidden-classes>
> > <non-overridable-classes>
> > <filter>java.</filter>
> > <filter>javax.</filter>
> >
> > Modified: geronimo/server/trunk/configs/tomcat6-deployer/src/main/
> > plan/plan.xml
> > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
> > tomcat6-deployer/src/main/plan/plan.xml?
> > rev=574694&r1=574693&r2=574694&view=diff
> > ======================================================================
> > ========
> > --- geronimo/server/trunk/configs/tomcat6-deployer/src/main/plan/
> > plan.xml (original)
> > +++ geronimo/server/trunk/configs/tomcat6-deployer/src/main/plan/
> > plan.xml Tue Sep 11 14:21:15 2007
> > @@ -70,7 +70,10 @@
> > <type>car</type>
> > </dependency>
> > </dependencies>
> > - <hidden-classes/>
> > + <hidden-classes>
> > + <filter>org.springframework.</filter>
> > + <filter>META-INF/spring</filter>
> > + </hidden-classes>
> > <non-overridable-classes>
> > <filter>java.</filter>
> > <filter>javax.</filter>
> >
> > Modified: geronimo/server/trunk/configs/tomcat6-deployer/src/plan/
> > plan.xml
> > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
> > tomcat6-deployer/src/plan/plan.xml?
> > rev=574694&r1=574693&r2=574694&view=diff
> > ======================================================================
> > ========
> > --- geronimo/server/trunk/configs/tomcat6-deployer/src/plan/
> > plan.xml (original)
> > +++ geronimo/server/trunk/configs/tomcat6-deployer/src/plan/
> > plan.xml Tue Sep 11 14:21:15 2007
> > @@ -70,7 +70,10 @@
> > <type>car</type>
> > </dependency>
> > </dependencies>
> > - <hidden-classes/>
> > + <hidden-classes>
> > + <filter>org.springframework.</filter>
> > + <filter>META-INF/spring</filter>
> > + </hidden-classes>
> > <non-overridable-classes>
> > <filter>java.</filter>
> > <filter>javax.</filter>
> >
> > Modified: geronimo/server/trunk/modules/geronimo-cxf/src/main/java/
> > org/apache/geronimo/cxf/CXFWebServiceContainer.java
> > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
> > geronimo-cxf/src/main/java/org/apache/geronimo/cxf/
> > CXFWebServiceContainer.java?rev=574694&r1=574693&r2=574694&view=diff
> > ======================================================================
> > ========
> > --- geronimo/server/trunk/modules/geronimo-cxf/src/main/java/org/
> > apache/geronimo/cxf/CXFWebServiceContainer.java (original)
> > +++ geronimo/server/trunk/modules/geronimo-cxf/src/main/java/org/
> > apache/geronimo/cxf/CXFWebServiceContainer.java Tue Sep 11 14:21:15
> > 2007
> > @@ -132,8 +132,22 @@
> > * be (re)used in other places.
> > */
> > public static Bus getBus() {
> > - BusFactory.getDefaultBus();
> > + getDefaultBus();
> > return new ExtensionManagerBus();
> > }
> > -
> > +
> > + /*
> > + * Ensure the Spring bus is initialized with the CXF module
> > classloader
> > + * instead of the application classloader.
> > + */
> > + public static Bus getDefaultBus() {
> > + ClassLoader cl = Thread.currentThread
> > ().getContextClassLoader();
> > + Thread.currentThread().setContextClassLoader
> > (CXFEndpoint.class.getClassLoader());
> > + try {
> > + return BusFactory.getDefaultBus();
> > + } finally {
> > + Thread.currentThread().setContextClassLoader(cl);
> > + }
> > + }
> > +
> > }
> >
> > Modified: geronimo/server/trunk/modules/geronimo-cxf/src/main/java/
> > org/apache/geronimo/cxf/client/CXFServiceReference.java
> > URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/
> > geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/
> > CXFServiceReference.java?rev=574694&r1=574693&r2=574694&view=diff
> > ======================================================================
> > ========
> > --- geronimo/server/trunk/modules/geronimo-cxf/src/main/java/org/
> > apache/geronimo/cxf/client/CXFServiceReference.java (original)
> > +++ geronimo/server/trunk/modules/geronimo-cxf/src/main/java/org/
> > apache/geronimo/cxf/client/CXFServiceReference.java Tue Sep 11
> > 14:21:15 2007
> > @@ -30,6 +30,7 @@
> > import org.apache.cxf.jaxws.context.WebServiceContextImpl;
> > import org.apache.cxf.jaxws.javaee.HandlerChainsType;
> > import org.apache.geronimo.cxf.CXFHandlerResolver;
> > +import org.apache.geronimo.cxf.CXFWebServiceContainer;
> > import org.apache.geronimo.gbean.AbstractName;
> > import org.apache.geronimo.jaxws.HandlerChainsUtils;
> > import org.apache.geronimo.jaxws.JAXWSAnnotationProcessor;
> > @@ -52,6 +53,7 @@
> > }
> >
> > public Object getContent() throws NamingException {
> > + CXFWebServiceContainer.getDefaultBus();
> > Object reference = super.getContent();
> > SAAJInterceptor.registerInterceptors();
> > return reference;
> >
> >
>
>
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Jarek Gawor <jg...@gmail.com>.
FYI, just added a spring/car module to trunk and hooked it up with
CXF. We can try doing the same with Pluto/new console now.
Jarek
On 9/19/07, Jarek Gawor <jg...@gmail.com> wrote:
> On 9/17/07, Paul McMahan <pa...@gmail.com> wrote:
> > > Maybe for now we should remove the filtering from web deployers and
> > > let each application configure the Spring filtering if necessary.
> >
> > Agreed and the idea about using a configuration for spring could be
> > promising too.
>
> Ok. I removed the filtering in trunk (and left it as is in branches/2.0).
>
> I will also try to work on the Spring/car module and see if it works with CXF.
>
> Jarek
>
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Jarek Gawor <jg...@gmail.com>.
On 9/17/07, Paul McMahan <pa...@gmail.com> wrote:
> > Maybe for now we should remove the filtering from web deployers and
> > let each application configure the Spring filtering if necessary.
>
> Agreed and the idea about using a configuration for spring could be
> promising too.
Ok. I removed the filtering in trunk (and left it as is in branches/2.0).
I will also try to work on the Spring/car module and see if it works with CXF.
Jarek
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Paul McMahan <pa...@gmail.com>.
On Sep 17, 2007, at 4:15 PM, Jarek Gawor wrote:
> Moving the filter from web deployer to cxf deployer will have no
> effect on your app. The application will always end up with the same
> filter in either setup. It will only work ok, if the filter is in
> cxf-deployer *and* if you use Tomcat or configure Axis2 as the JAX-WS
> engine. So moving the filter is better but it's definitely not a fool
> proof solution.
OK thanks for the clarification.
> Maybe for now we should remove the filtering from web deployers and
> let each application configure the Spring filtering if necessary.
Agreed and the idea about using a configuration for spring could be
promising too.
Best wishes,
Paul
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Jarek Gawor <jg...@gmail.com>.
On 9/17/07, Paul McMahan <pa...@gmail.com> wrote:
> > Moving the Spring filters to cxf-deployer is better from the
> > modularity point of view (and I'm all for it) but the end results will
> > be the same in this case. I think Kevan's idea might be the best
> > solution here.
>
> The end results here being that Spring-based webapps that contain web
> services would inherit cxf's copy of Spring? Or that cxf could not
> use Spring to configure itself? Or something else? I'm still not
> clear on what breaks or becomes more difficult if we move the filter
> to cxf-deployer or remove it altogether.
Moving the filter from web deployer to cxf deployer will have no
effect on your app. The application will always end up with the same
filter in either setup. It will only work ok, if the filter is in
cxf-deployer *and* if you use Tomcat or configure Axis2 as the JAX-WS
engine. So moving the filter is better but it's definitely not a fool
proof solution.
Maybe for now we should remove the filtering from web deployers and
let each application configure the Spring filtering if necessary.
Jarek
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Paul McMahan <pa...@gmail.com>.
On Sep 17, 2007, at 12:48 PM, Jarek Gawor wrote:
> Paul,
>
> In the new admin console, do the web applications (that provide
> portlets) need to share Spring version/configuration with the Pluto
> config module? What if each web application had its own Spring jars?
> Would that work?
Actually the portlet webapps don't need to share Spring, they need to
share Pluto. Pluto needs to be in a parent configuration for those
webapps so that they can know about each other's portlets via the
classloader. The tricky part here is that Pluto uses Spring
internally for configuration and needs for it to be in the same
classloader as the Pluto jars. So this is not a clear cut case of
apps needing to share Spring but rather apps needing to share
something that depends on Spring. In fact this might be a more
common scenario than sharing Spring itself since nowadays many
components use Spring for configuration.
> Moving the Spring filters to cxf-deployer is better from the
> modularity point of view (and I'm all for it) but the end results will
> be the same in this case. I think Kevan's idea might be the best
> solution here.
The end results here being that Spring-based webapps that contain web
services would inherit cxf's copy of Spring? Or that cxf could not
use Spring to configure itself? Or something else? I'm still not
clear on what breaks or becomes more difficult if we move the filter
to cxf-deployer or remove it altogether.
I'm wondering if we can target our solution only at assemblies that
contain cxf since the current solution affects the minimal and axis
based assemblies where it may not be needed. I guess that's in line
with your comment about modularity, and I agree with you and Kevan
that a new classloader knob for deployment plans is probably the best
way to accomplish this.
Best wishes,
Paul
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Jarek Gawor <jg...@gmail.com>.
Paul,
In the new admin console, do the web applications (that provide
portlets) need to share Spring version/configuration with the Pluto
config module? What if each web application had its own Spring jars?
Would that work?
Moving the Spring filters to cxf-deployer is better from the
modularity point of view (and I'm all for it) but the end results will
be the same in this case. I think Kevan's idea might be the best
solution here.
Jarek
On 9/17/07, Paul McMahan <pa...@gmail.com> wrote:
> On Sep 14, 2007, at 7:58 PM, Kevan Miller wrote:
>
> > Heh. Well, I had hopes for Paul's proposal... Sounds like it's
> > still better than where we are now...
>
> I was also thinking that it's a step forward, but now it's not clear
> to me whether moving the spring filter to cxf-deployer would break
> cxf's spring-related stuff, or just leave us with some non-critical
> issues to resolve. If it's the latter case then can we commit as an
> interim step so the admin console can start working again?
>
> > I think the right way to address the problem is at the CXF module,
> > itself (which we've talked about on other threads). Basic idea is
> > that the CXF module would declare the classes that it will hide
> > from classloader children.
> >
> > You'd specify something like:
> >
> > <child-hidden-classes>
> > <filter>org.springframework.</filter>
> > <filter>META-INF/spring</filter>
> > </child-hidden-classes>
> >
> > The CXF module classloader would hide these classes/resources from
> > child classloaders. We could also consider separating <hidden-
> > classes> and <hidden-resources>...
>
> I think that the more we can attach the filters to the actual
> components that need them the better, so I really like your idea.
> Another variation would be to extend the <inverse-classloading>
> element that Geronimo currently supports to include filters that
> affect whether child components get the parents' or their own
> versions of certain classes. i.e. something like:
>
> <inverse-classloading>
> <filter>org.springframework.</filter>
> </inverse-classloading>
>
> would tell Geronimo to prefer loading the spring classes from the
> child's classloader.
>
> > Other final (?) thing to consider is creating a Spring module. Both
> > cxf and pluto-support could depend on this new module...
>
> I thought about this too but couldn't think of a way for apps to
> share the Spring classes in a classloader without potentially
> stomping on each other's spring configuration and bean factories.
>
>
> Best wishes,
> Paul
>
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Paul McMahan <pa...@gmail.com>.
On Sep 14, 2007, at 7:58 PM, Kevan Miller wrote:
> Heh. Well, I had hopes for Paul's proposal... Sounds like it's
> still better than where we are now...
I was also thinking that it's a step forward, but now it's not clear
to me whether moving the spring filter to cxf-deployer would break
cxf's spring-related stuff, or just leave us with some non-critical
issues to resolve. If it's the latter case then can we commit as an
interim step so the admin console can start working again?
> I think the right way to address the problem is at the CXF module,
> itself (which we've talked about on other threads). Basic idea is
> that the CXF module would declare the classes that it will hide
> from classloader children.
>
> You'd specify something like:
>
> <child-hidden-classes>
> <filter>org.springframework.</filter>
> <filter>META-INF/spring</filter>
> </child-hidden-classes>
>
> The CXF module classloader would hide these classes/resources from
> child classloaders. We could also consider separating <hidden-
> classes> and <hidden-resources>...
I think that the more we can attach the filters to the actual
components that need them the better, so I really like your idea.
Another variation would be to extend the <inverse-classloading>
element that Geronimo currently supports to include filters that
affect whether child components get the parents' or their own
versions of certain classes. i.e. something like:
<inverse-classloading>
<filter>org.springframework.</filter>
</inverse-classloading>
would tell Geronimo to prefer loading the spring classes from the
child's classloader.
> Other final (?) thing to consider is creating a Spring module. Both
> cxf and pluto-support could depend on this new module...
I thought about this too but couldn't think of a way for apps to
share the Spring classes in a classloader without potentially
stomping on each other's spring configuration and bean factories.
Best wishes,
Paul
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/ modules/geronimo-cxf/src/main/java/org/apache/ger
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 14, 2007, at 2:56 PM, Jarek Gawor wrote:
> Ugh... I had a feeling that this filtering will cause problems for
> someone. Anyway, in general I think moving the hidden-classes filter
> to the CXF deployer is a better solution (to keep it all together and
> assuming it has the same effect as when specified in the web container
> deployer). But, in this case I don't think this will work right still.
> First, in CXF there are two key deployers. One that handles deployment
> of web services and another one that handles service references (it's
> a naming builder). Both will need the hidden-classes filter (the patch
> only updates the web service deployer). However, because the way
> currently the naming builders work in Geronimo, the environment of
> naming builders is always merged no matter if the application has a
> service reference or not (or whatever the naming builder is looking
> for). So at the end, even if we moved the hidden-classes filter to the
> CXF deployers, the filter will still be injected. So we might need to
> fix how the naming builders work or find a better way to deal with
> Spring filtering. I'm not sure what's the right solution here.
Heh. Well, I had hopes for Paul's proposal... Sounds like it's still
better than where we are now...
I think the right way to address the problem is at the CXF module,
itself (which we've talked about on other threads). Basic idea is
that the CXF module would declare the classes that it will hide from
classloader children.
You'd specify something like:
<child-hidden-classes>
<filter>org.springframework.</filter>
<filter>META-INF/spring</filter>
</child-hidden-classes>
The CXF module classloader would hide these classes/resources from
child classloaders. We could also consider separating <hidden-
classes> and <hidden-resources>...
Other final (?) thing to consider is creating a Spring module. Both
cxf and pluto-support could depend on this new module...
--kevan