cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@verizon.net>
Subject Re: Thoughts about supporting run CXFServlet without Spring
Date Wed, 31 Oct 2007 02:37:14 GMT
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
> >
> >
> >   


Mime
View raw message