cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <>
Subject Re: Thoughts about supporting run CXFServlet without Spring
Date Tue, 30 Oct 2007 14:37:18 GMT
Am Dienstag, den 30.10.2007, 17:46 +0800 schrieb Willem Jiang:
> Hi,
> Today, I tried you let the CXFServlet work without the Spring support.

I'm not sure why we need to bother doing this.  While the submitter[1]
may be correct that it might not take much additional effort for us to
support Spring and non-Spring configuration, that doesn't necessarily
mean we should do that.


> I almost get there by commenting out XmlBeanDefinitionReader related 
> staff in the CXFServlet.loadAdditionalConfig method.
> Here is my question,  why the class loader will load the 
> XmlBeanDefinitionReader's construction parameter class 
> BeanDefinitionRegistry first when CXFServlet is created?
> I can't see any static code relates to the XmlBeanDefinitionReader in 
> CXF Servlet.

I think that is done somewhere "automatically" by the Spring framework,
but am unsure on that point.  (Does CXFServlet extend a Spring-based

Keep in mind, in the future, if there is a problem with synchronization
of multiple configuration files, perhaps we can alter CXFServlet to
allow it to accept multiple config files in the web.xml just like Spring
MVC's DispatcherServlet:

(But that above functionality may already be available to *any* servlet
that extends one from the Spring framework--so we might be able to do
this right now with CXFServlet.)

> Can anyone tell me what I'm missing?
> If there is not a way to walk around it , I suppose to write another 
> CXFServlet which has nothing to do with the Spring's stuff.

[For those who would like to see a comparison, Step #8 of the example
below shows CXF's Spring-based configuration and Sun's Spring-free

Unless there is a really valid reason, I don't think we would want to
maintain two separate configuration systems.  The user is not stating
any problem with Spring configuration--he just says he doesn't like
Spring.  So you may not be able to win offering a Spring-free
configuration, because the next step he will want is a Spring-free

For the few that simply cannot use Spring configuration at all, they can
use Metro instead.  We presumably get folks from Metro who like Spring
configuration--especially since Metro's configuration isn't documented
very well--so it can be a benefit for us also.

I know it's tough to sometimes send people to a competing product, but
if the amount of effort needed to please a small amount of people takes
away too from much from adding features elsewhere, then even *more*
people end up going to that competing product because of the lost
progress in those other areas.


View raw message