You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Willem Jiang <ni...@iona.com> on 2007/10/30 10:46:34 UTC
Thoughts about supporting run CXFServlet without Spring
Hi,
Today, I tried you let the CXFServlet work without the Spring support.
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.
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.
Here is my test code for testing the CXFServlet.
public class JettyServer {
public static void main(String[] args) throws Exception {
Server httpServer = new Server(9000);
ContextHandlerCollection contexts = new ContextHandlerCollection();
httpServer.setHandler(contexts);
Context root = new Context(contexts,"/",Context.SESSIONS);
CXFServlet cxf = new CXFServlet();
ServletHolder servlet = new ServletHolder(cxf);
servlet.setName("soap");
servlet.setForcedPath("soap");
root.addServlet(servlet, "/soap/*");
httpServer.start();
Bus bus = cxf.getBus();
BusFactory.setDefaultBus(bus);
// register service
String uri = "/" +GreeterImpl.class.getSimpleName();
System.out.println(uri);
Endpoint.publish(uri, new GreeterImpl());
Endpoint.publish("/hello", new HelloImpl());
}
}
Re: Thoughts about supporting run CXFServlet without Spring
Posted by Glen Mazza <gl...@verizon.net>.
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
> >
> >
> >
Re: Thoughts about supporting run CXFServlet without Spring
Posted by Willem Jiang <ni...@iona.com>.
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
>
>
>
Re: Thoughts about supporting run CXFServlet without Spring
Posted by Glen Mazza <gl...@verizon.net>.
Am Dienstag, den 30.10.2007, 10:37 -0400 schrieb Glen Mazza:
>
> 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.
>
Oops, conflict-of-interest disclosure necessary--I have write access to
the Metro user's guide[1] (although not Metro itself) and sometimes
update it. Call me "the team skunk"... ;-)
Glen
[1] https://jax-ws.dev.java.net/guide/
> Glen
>
>
Re: Thoughts about supporting run CXFServlet without Spring
Posted by Glen Mazza <gl...@verizon.net>.
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