Well, you definitely know more about this than I do. I guess would be more comfortable though if I understood what the problem was about using Spring configuration. But if this change becomes a problem in the future we can always deprecate and then remove the second servlet.
Glen Am Mittwoch, den 31.10.2007, 09:57 +0800 schrieb Willem Jiang: > Hi Glen, > > I think it is easy for us to support the non-Spring configuration in the > Servlet transport because we already has the CXFBusFactory to load a bus > without any help of the Spring. > > All I need to do is some clean up work , isolating the Spring related > stuff in CXFServlet and using another non-Spring Servlet to setup the > bus and load the endpoint publish information. > > BTW, > Current CXFSerlvet does not extend any Spring based servlet. > > Willem. > > Glen Mazza wrote: > > 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 > > > > > >
