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
