geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject 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
Date Fri, 14 Sep 2007 23:58:18 GMT

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

Mime
View raw message