cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: mutithread issues in interceptors and endpoints
Date Fri, 22 Feb 2008 15:19:13 GMT
On Friday 22 February 2008, Davide Gesino wrote:
> >>  In CXF there is a single instance of any endpoint bean that
> >> manages all the incoming requests, or somehow there is way to have
> >> a pool of endpoints?
> >
> > With a little bit of code, yes.  You can can configure in your own
> > invoker that does something diffent.   If you look in
> > org.apache.cxf.jaxws.JAXWSMethodInvoker and it's super classes,
> > there are various ways to configure other policies.   The simplest
> > way would be to just subclass it and overwride the getServiceObject
> > and releaseServiceObject methods to do whatever you need them to do.
> > Those methods would be called for each invokation, but they could
> > return an instance from a pool, create a new one for each invoke,
> > etc...
> For the endpoint invocation the defauls is
> org.apache.cxf.jaxws.JAXWSMethodInvoker that inherit from
> FactoryInvoker. So each time I call a remote method a new endpoint
> instance is created? To use a single instance should I have to use
> BeanInvoker?

No, the default is actually single instance.  If you look in the 
JAXWSMethodInvoker constructor, the default is to create a Factory that 
just returns the single instance.   Thus, you have to go out of your way 
to not have that behavior.

Looking at the code (this seems to be some code that came from XFire), 
there is some ScopePolicy things that seem to do various things, but 
they seem to be very confusing and also won't work with the 
JAXWSMethodInvoker anyway due to that singleton factory thing.    
There's PROBABLY a way to use the 
org.apache.cxf.service.invoker.LocalFactory with a  RequestScopePolicy 
thing to have it create a new instance of each request.   Maybe.  I'm 
not really sure if any of that is working and it's all very confusing.  
I'm tempted to rip that all out and just have a couple different 
factories.  (SingleInstanceFactory, PerRequestFactory, SessionFactory, 
PooledFactory,  etc...)

That all said, it's probably just easier to subclass the 
JAXWSMethodInvoker and overwride the getServiceObject and  
releaseServiceObject methods to do what you need.   Ideally, the 
factorys could do that, but that seems very complicated right now (and 
the factories aren't hooked into the release stuff at all, which isn't 

> > Seriously, if you need to pass values to other interceptors along
> > the same chain, etc... you should store them in the Message or in
> > the exchange.  (msg.getExchange()).     If you need to hold some
> > state for a session, grab the HttpRequest from the msg and create an
> > http session. Any instance variables would need to be properly
> > protected as they would apply for all invokations of that endpoint. 
> >  (example: use an AtomicInteger for a "hit count" type thing)
> considering JAX-WS handler instead of interceptor is the same thing?
> The safe place where to store request variables in a handler is the
> context itself(and access them injecting the Web ServiceContext in the
> endpoint) ?? something similar to:
> public boolean handleMessage(SOAPMessageContext ctx) {
> ctx.put("KEY","VALUE");
> ...

Yep.   However, with JAX-WS handlers, you would need to set the Scope as 
well:   ctx.setScope("KEY", Scope.APPLICATION)
The default in handlers is Handler scope.  Thus, those values will be 
available to other handlers, but not to the application code.   

J. Daniel Kulp
Principal Engineer, IONA

View raw message