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
