You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Orban, Gyorgy (IT)" <Gy...@MorganStanley.com> on 2008/10/09 17:49:28 UTC
cxf-spring integration questions
Hi,
I would like to ask for some guidance on using CXF together with Spring, more specifically in terms of lifecycle management. There seems to be two ways how CXF can be integrated with Spring:
1) It can be embedded in Spring as outlined in http://cwiki.apache.org/CXF20DOC/deploymentspring.html. In this case, the user's application context imports the cxf spring configuration and the CXF runtime will be in the same context as the application. For servlet environment, this seems to be the only option.
2) CXF can start up a separate context (bus application context) for its runtime. Config example for this can be found at http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html (first config, no imports).
CXF seems to have its own lifecycle manager component implemented in CXFBusLifeCycleManager, which can control the spring context through org.apache.cxf.bus.spring.SpringBusFactory.BusApplicationContextLifeCycleListener in case 2).
However, if a user chooses to embed cxf in the spring context (case 1) of his application there seems to be no default mapping from some of the spring lifecycle events to the bus events. For example, CXFBusImpl.shutdown() does not get called when spring closes the context because it does not hook into Spring's destroy callback, which leaves servers running after the user application context is shut down. Is there any reason why that is not done automatically? For example, we need to do this now to get servers shut down properly:
public class CXFBusSpringLifecycleBridge implements InitializingBean, DisposableBean {
@Resource(name = "org.apache.cxf.buslifecycle.BusLifeCycleManager")
private org.apache.cxf.buslifecycle.BusLifeCycleManager busLifeCycleManager;
@Resource(name = Bus.DEFAULT_BUS_ID)
private Bus bus;
...
@Override
public void destroy() throws Exception {
((CXFBusImpl) bus).shutdown(true);
}
}
Also, could you please advise on what would be the best way of delegating Spring's org.springframework.context.Lifecycle start() and stop() events to cxf servers? org.apache.cxf.endpoint.Server.start() and stop() seems to have the same semantics as Lifecycle.start() and stop(), so could CXF maybe implement the spring Lifecycle interface directly?
Another problem around spring integration seems to be that it includes a Jsr250BeanPostProcessor by default, which pollutes the user's config in case 1. Should that be maybe made optional similarly to the extensions?
Thanks,
Gyorgy
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: cxf-spring integration questions
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 09 October 2008 11:49:28 am Orban, Gyorgy (IT) wrote:
> 1) It can be embedded in Spring as outlined in
> http://cwiki.apache.org/CXF20DOC/deploymentspring.html. In this case, the
> user's application context imports the cxf spring configuration and the CXF
> runtime will be in the same context as the application. For servlet
> environment, this seems to be the only option.
>
> 2) CXF can start up a separate context (bus application context) for its
> runtime. Config example for this can be found at
> http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html (first config,
> no imports).
This can be done in the servlet case as well with a WEB-INF/cxf-servlet.xml.
Not too popular though as it does limit what can be configured.
> CXF seems to have its own lifecycle manager component implemented in
> CXFBusLifeCycleManager, which can control the spring context through
> org.apache.cxf.bus.spring.SpringBusFactory.BusApplicationContextLifeCycleLi
>stener in case 2).
>
> However, if a user chooses to embed cxf in the spring context (case 1) of
> his application there seems to be no default mapping from some of the
> spring lifecycle events to the bus events. For example,
> CXFBusImpl.shutdown() does not get called when spring closes the context
> because it does not hook into Spring's destroy callback, which leaves
> servers running after the user application context is shut down. Is there
> any reason why that is not done automatically? For example, we need to do
> this now to get servers shut down properly:
A bug probably should be logged here. It probably should have a shutdown
hook registered with spring. (and patch would be nice too with the grant to
apache box checked ;-)
> Also, could you please advise on what would be the best way of delegating
> Spring's org.springframework.context.Lifecycle start() and stop() events to
> cxf servers? org.apache.cxf.endpoint.Server.start() and stop() seems to
> have the same semantics as Lifecycle.start() and stop(), so could CXF maybe
> implement the spring Lifecycle interface directly?
Many parts of CXF need to be usable without the spring jars so they cannot
implement them directly. HOWEVER, we also use spring specific subclasses
in a bunch of cases that COULD implement them. For example, in the
org.apache.cxf.jaxws.spring.EndpointDefinitionParser class that handles the
jaxws:endpoint things, it parsed into a special SpringEndpointImpl. That
COULD (and does) implement spring specific stuff. This could be expanded to
other areas as well. Again, jira's and patches are quite welcome.
> Another problem around spring integration seems to be that it includes a
> Jsr250BeanPostProcessor by default, which pollutes the user's config in
> case 1. Should that be maybe made optional similarly to the extensions?
Well, there is a lot of stuff in CXF itself that is wired together with the
@Resource/@PostConstruct annotations that that bean post processor handles.
Thus, a lot of stuff will fail if it it's not there. What's the problem
with it?
I know one issue is that if you have Springs jsr250 processor enabled, the
stuff gets called twice. One option I want to try for that is to add:
@Resource
Bus bus
to the Jsr250BeanPostProcessor. If bus is not null in the process methods,
then the Spring 250 processor is enabled (and has injected the Bus) and will
handle things. If it IS null, then the spring one is not enabled and we
need to handle it. I definitely need to verify that though and probably
run the full test suite with the spring processor turned on to make sure the
bus is completely setup properly.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog