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. [1] https://issues.apache.org/jira/browse/CXF-1072 > 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 Servlet?) 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: http://www.jroller.com/gmazza/date/20061128 (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 one: http://www.jroller.com/gmazza/date/20071019#step8 ] 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 architecture. 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. Glen
