Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: cxf-spring integration questions
Date: Thu, 9 Oct 2008 12:57:21 -0400
User-Agent: KMail/1.9.9
Cc: "Orban, Gyorgy \(IT\)" <Gyorgy.Orban@morganstanley.com>,
 "Kralj-Taylor, Mark \(IT\)" <Mark.Kralj-Taylor@morganstanley.com>,
 "Rowlands, Ben \(IT\)" <Ben.Rowlands@morganstanley.com>,
 "McClelland, Chris \(IT\)" <Chris.McClelland@morganstanley.com>,
 "Goldspink, Matt \(IT\)" <Matthew.Goldspink@morganstanley.com>
References: 
 <0FE1D5D2B5C6754898C9E32C1230EC652E3C55449C@LNWEXMBX0105.msad.ms.com>
In-Reply-To: 
 <0FE1D5D2B5C6754898C9E32C1230EC652E3C55449C@LNWEXMBX0105.msad.ms.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200810091257.21536.dkulp@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