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
[EMAIL PROTECTED]
http://dankulp.com/blog