You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Alex O'Ree <sp...@gmail.com> on 2012/03/18 21:58:00 UTC
Interceptor map persistence?
I'm writing a pair of POST_LOGICAL interceptors and need to be able to
pass some variables that are discovered on the request flow, to the
response flow.
In other frameworks, I've been able to just add what I need into the
message request context (org.apache.cxf.message.Message) and it
magically appears when the response handler chain fires off. This
doesn't appear to be the case for cxf. Can only confirm this behavior?
Better yet, does anyone know of a work around or an alternate
mechanism? I'm thinking that perhaps I'm using the wrong phase to do
such a task.
Ironically, if I used a jaxws handler, the values added in the request
context are available in the response context.
Re: Interceptor map persistence?
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday, March 18, 2012 04:58:00 PM Alex O'Ree wrote:
> I'm writing a pair of POST_LOGICAL interceptors and need to be able to
> pass some variables that are discovered on the request flow, to the
> response flow.
>
> In other frameworks, I've been able to just add what I need into the
> message request context (org.apache.cxf.message.Message) and it
> magically appears when the response handler chain fires off. This
> doesn't appear to be the case for cxf. Can only confirm this behavior?
Yes. The "Message" object just represents the information and context
around that particular message.
However, the message does hold onto an Exchange object which represents the
entire exchange, including the incoming and outgoing messages. In your
case, call message.getExchange().put(...) and you could retrieve it the
same way.
Dan
> Better yet, does anyone know of a work around or an alternate
> mechanism? I'm thinking that perhaps I'm using the wrong phase to do
> such a task.
>
> Ironically, if I used a jaxws handler, the values added in the request
> context are available in the response context.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Interceptor map persistence?
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday, March 18, 2012 08:49:03 PM Alex O'Ree wrote:
> Another related question.
>
> I was able to persist my variable using Bus.setProperty,
Likely not what you want.
> but what is
> the scope of this object?
> 1 per web service client
> 1 per thread
> 1 per application
Seriously, it could be any of the above depending on how it was created or
the context in which it's used. Could also be multples per application,
etc... When a client or service is created using pure JAX-WS API's, the
"default" bus is used. Thus, you can get into a single bus per JVM.
However, if you use spring or blueprint and the namespace handlers, you will
get a Bus specific for that application context. However, in all cases,
you can specifically configure in multiple "named" Bus's and assign them to
specific services.
> Although I'm kind of in a working state, I'm wondering if i'll run
> into concurrency issues
The bus is generally a registry of stuff common to a group of services or
clients. In general, this is stuff you want set on bunch of services, like
maybe turning on logging for a bunch of things or handling JMX stuff or
turning on schema validation across the board or similar. Definitely not
something you want on a "per request" basis.
Dan
>
> On Sun, Mar 18, 2012 at 4:58 PM, Alex O'Ree <sp...@gmail.com> wrote:
> > I'm writing a pair of POST_LOGICAL interceptors and need to be able to
> > pass some variables that are discovered on the request flow, to the
> > response flow.
> >
> > In other frameworks, I've been able to just add what I need into the
> > message request context (org.apache.cxf.message.Message) and it
> > magically appears when the response handler chain fires off. This
> > doesn't appear to be the case for cxf. Can only confirm this behavior?
> > Better yet, does anyone know of a work around or an alternate
> > mechanism? I'm thinking that perhaps I'm using the wrong phase to do
> > such a task.
> >
> > Ironically, if I used a jaxws handler, the values added in the request
> > context are available in the response context.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Interceptor map persistence?
Posted by Alex O'Ree <sp...@gmail.com>.
Another related question.
I was able to persist my variable using Bus.setProperty, but what is
the scope of this object?
1 per web service client
1 per thread
1 per application
Although I'm kind of in a working state, I'm wondering if i'll run
into concurrency issues
On Sun, Mar 18, 2012 at 4:58 PM, Alex O'Ree <sp...@gmail.com> wrote:
> I'm writing a pair of POST_LOGICAL interceptors and need to be able to
> pass some variables that are discovered on the request flow, to the
> response flow.
>
> In other frameworks, I've been able to just add what I need into the
> message request context (org.apache.cxf.message.Message) and it
> magically appears when the response handler chain fires off. This
> doesn't appear to be the case for cxf. Can only confirm this behavior?
> Better yet, does anyone know of a work around or an alternate
> mechanism? I'm thinking that perhaps I'm using the wrong phase to do
> such a task.
>
> Ironically, if I used a jaxws handler, the values added in the request
> context are available in the response context.