You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Fred Dushin <fr...@dushin.net> on 2007/03/20 22:02:28 UTC
Programatically installing interceptors per (Bus|Service|Endpoint)
I understand that CXF provides APIs for installed interceptors
through the InterceptorProvider interface, which the Bus, Endpoint,
and Service types all extend (among other types).
Suppose I want to create, via configuration, some sort of CXF plugin
(I hesitate to call this an interceptor, for reasons which should
become obvious). The purpose of this plugin is to install
interceptors programatically into the call chain.
I can see how to do this using a reference to a Bus -- e.g., I can
spring-load the plugin I want to install, and wire it up to the Bus
-- common pattern. And from there, I can get access to the Bus-level
InterceptorProvider, since the Bus extends that type.
That would work in the case where I want my plugin to install these
interceptors globally, i.e, for all services and endpoints in a Bus;
however, suppose I want to install my interceptors at a finer level
of granularity, e.g., per endpoint. Is there a way for my plugin,
which seems to be loaded at Bus initialization time, to get a handle
on the Service or Endpoint (which also implement InterceptorProvider)
for which it is (or counterfactually would be) configured? Is this
an envisioned pattern? Or is there some other sort of interceptor I
don't know of, e.g, which hooks into Service or Endpoint creation?
Thanks!
-Fred
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
All good points. I hadn't considered the need to set the order, only
that there is *an* order.
Again, wallowing in my own ignorance :)
-Fred
On Mar 21, 2007, at 5:13 PM, Daniel Kulp wrote:
>
> Fred,
>
> On Wednesday 21 March 2007 17:05, Fred Dushin wrote:
>> I'm not sure about that. TreeMaps are pretty lightweight -- they
>> only allocate an Entry (cons cell, effectively) for each entry in the
>> map. In-order traversals are O(n); lookups are O(lgn) (probably
>> \Theta(lgn)), but lookups are the degenerate case.
>>
>> I actually just did a little performance comparison -- Trees vs
>> Hashes, and for anything smaller than 10-15 entries, the comparative
>> cost of lookup is negligible, and the memory footprint is smaller
>> with sortable collections. Anyone want the test code? Just ask.
>
> I'm more concerned with the cost of the iterators of the "Thread Safe"
> variants of the various types: (the value set iterator on the maps)
>
> CopyOnWriteArrayList
> CopyOnWriteArraySet
> ConcurrentHashMap
> Collections.syncronizedMap(new TreeMap())
>
> Technically, I'd also argue that the TreeMap and HashMaps are NOT
> appropriate. The Lists provide and order of how the stuff are added
> into the chain. Thus, the only map that would really meet that is:
>
> Collections.syncronizedMap(new LinkedHashMap())
>
>
> Dan
>
>
>
>>
>> -Fred
>>
>> On Mar 21, 2007, at 4:29 PM, Daniel Kulp wrote:
>>> On Wednesday 21 March 2007 15:42, Fred Dushin wrote:
>>>> Someone else mentioned that it might be nice to have he notion of
>>>> an interceptor id, which I'd fully agree with, so that you could do
>>>> a lookup by id. Your interceptor lists are then just (sortable)
>>>> maps (or multimaps, as the case may be), and lookup can be done in
>>>> O(lg n). But that's a pretty disruptive change to the whole
>>>> architecture. OTOH, better to do it now than once the cat is out
>>>> of the bag...
>>>
>>> It also has nasty performance impacts as the traversals would be
>>> much more expensive. Since those traversals happen on EVERY SINGLE
>>> message,
>>> that would be really bad. Also, maps use significantly more memory
>>> than the ArrayLists do.
>>>
>>> My only real thought on this would be to change from List to Set
>>> and use
>>> the CopyOnWriteArraySet. That keeps the performance of the
>>> ArrayList for the traversals. It also gives you the guarantee of
>>> uniqueness in the Set. (providing you write an appropriate
>>> .equals(...) method) The main cost is more expensive "add",
>>> "remove", and "contains" methods.
>>> However, that should be a startup cost in 95% of the cases.
>>>
>>> Anyway, it's a thought.
>>>
>>> --
>>> J. Daniel Kulp
>>> Principal Engineer
>>> IONA
>>> P: 781-902-8727 C: 508-380-7194
>>> daniel.kulp@iona.com
>>> http://www.dankulp.com/blog
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Daniel Kulp <dk...@apache.org>.
Fred,
On Wednesday 21 March 2007 17:05, Fred Dushin wrote:
> I'm not sure about that. TreeMaps are pretty lightweight -- they
> only allocate an Entry (cons cell, effectively) for each entry in the
> map. In-order traversals are O(n); lookups are O(lgn) (probably
> \Theta(lgn)), but lookups are the degenerate case.
>
> I actually just did a little performance comparison -- Trees vs
> Hashes, and for anything smaller than 10-15 entries, the comparative
> cost of lookup is negligible, and the memory footprint is smaller
> with sortable collections. Anyone want the test code? Just ask.
I'm more concerned with the cost of the iterators of the "Thread Safe"
variants of the various types: (the value set iterator on the maps)
CopyOnWriteArrayList
CopyOnWriteArraySet
ConcurrentHashMap
Collections.syncronizedMap(new TreeMap())
Technically, I'd also argue that the TreeMap and HashMaps are NOT
appropriate. The Lists provide and order of how the stuff are added
into the chain. Thus, the only map that would really meet that is:
Collections.syncronizedMap(new LinkedHashMap())
Dan
>
> -Fred
>
> On Mar 21, 2007, at 4:29 PM, Daniel Kulp wrote:
> > On Wednesday 21 March 2007 15:42, Fred Dushin wrote:
> >> Someone else mentioned that it might be nice to have he notion of
> >> an interceptor id, which I'd fully agree with, so that you could do
> >> a lookup by id. Your interceptor lists are then just (sortable)
> >> maps (or multimaps, as the case may be), and lookup can be done in
> >> O(lg n). But that's a pretty disruptive change to the whole
> >> architecture. OTOH, better to do it now than once the cat is out
> >> of the bag...
> >
> > It also has nasty performance impacts as the traversals would be
> > much more expensive. Since those traversals happen on EVERY SINGLE
> > message,
> > that would be really bad. Also, maps use significantly more memory
> > than the ArrayLists do.
> >
> > My only real thought on this would be to change from List to Set
> > and use
> > the CopyOnWriteArraySet. That keeps the performance of the
> > ArrayList for the traversals. It also gives you the guarantee of
> > uniqueness in the Set. (providing you write an appropriate
> > .equals(...) method) The main cost is more expensive "add",
> > "remove", and "contains" methods.
> > However, that should be a startup cost in 95% of the cases.
> >
> > Anyway, it's a thought.
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
I'm not sure about that. TreeMaps are pretty lightweight -- they
only allocate an Entry (cons cell, effectively) for each entry in the
map. In-order traversals are O(n); lookups are O(lgn) (probably
\Theta(lgn)), but lookups are the degenerate case.
I actually just did a little performance comparison -- Trees vs
Hashes, and for anything smaller than 10-15 entries, the comparative
cost of lookup is negligible, and the memory footprint is smaller
with sortable collections. Anyone want the test code? Just ask.
-Fred
On Mar 21, 2007, at 4:29 PM, Daniel Kulp wrote:
> On Wednesday 21 March 2007 15:42, Fred Dushin wrote:
>> Someone else mentioned that it might be nice to have he notion of an
>> interceptor id, which I'd fully agree with, so that you could do a
>> lookup by id. Your interceptor lists are then just (sortable) maps
>> (or multimaps, as the case may be), and lookup can be done in O(lg
>> n). But that's a pretty disruptive change to the whole
>> architecture. OTOH, better to do it now than once the cat is out of
>> the bag...
>
> It also has nasty performance impacts as the traversals would be much
> more expensive. Since those traversals happen on EVERY SINGLE
> message,
> that would be really bad. Also, maps use significantly more memory
> than the ArrayLists do.
>
> My only real thought on this would be to change from List to Set
> and use
> the CopyOnWriteArraySet. That keeps the performance of the ArrayList
> for the traversals. It also gives you the guarantee of uniqueness in
> the Set. (providing you write an appropriate .equals(...) method)
> The main cost is more expensive "add", "remove", and "contains"
> methods.
> However, that should be a startup cost in 95% of the cases.
>
> Anyway, it's a thought.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 21 March 2007 15:42, Fred Dushin wrote:
> Someone else mentioned that it might be nice to have he notion of an
> interceptor id, which I'd fully agree with, so that you could do a
> lookup by id. Your interceptor lists are then just (sortable) maps
> (or multimaps, as the case may be), and lookup can be done in O(lg
> n). But that's a pretty disruptive change to the whole
> architecture. OTOH, better to do it now than once the cat is out of
> the bag...
It also has nasty performance impacts as the traversals would be much
more expensive. Since those traversals happen on EVERY SINGLE message,
that would be really bad. Also, maps use significantly more memory
than the ArrayLists do.
My only real thought on this would be to change from List to Set and use
the CopyOnWriteArraySet. That keeps the performance of the ArrayList
for the traversals. It also gives you the guarantee of uniqueness in
the Set. (providing you write an appropriate .equals(...) method)
The main cost is more expensive "add", "remove", and "contains" methods.
However, that should be a startup cost in 95% of the cases.
Anyway, it's a thought.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
Answering my own question here, after consultation with some CXF devs.
The anwser is, the lists returned from interceptors are returned from
the InterceptorProviders can and should be thread-safe, but it's a
current limitation that they are not. I've submitted https://
issues.apache.org/jira/browse/CXF-480 and am running the build on a
patch, which I'll submit shortly.
This still does not mean that one is completely out of the woods --
concurrent access to the interceptor list is safe, but you are still
not guaranteed that another thread hasn't already added (or removed)
an interceptor you may be looking for as you traverse it.
In my particular case, this should not be an issue, since I have
control over which interceptor (types) I am looking for and
inserting, but buyer beware, in the general case.
I suppose a general pattern we might adopt and urge on applications
is to acquire a lock on the list, itself, whilst traversing and
inserting or removing elements, e.g.,
synchronized(interceptorList) {
// look for the interceptor I want to add
// if it's not there, add it
// leave a breadcrumb so I know I already inserted it
}
That sort of thing. Not sure what else can be said, other than a C++-
style ::insert.
Someone else mentioned that it might be nice to have he notion of an
interceptor id, which I'd fully agree with, so that you could do a
lookup by id. Your interceptor lists are then just (sortable) maps
(or multimaps, as the case may be), and lookup can be done in O(lg
n). But that's a pretty disruptive change to the whole
architecture. OTOH, better to do it now than once the cat is out of
the bag...
-Fred
On Mar 21, 2007, at 5:48 AM, Fred Dushin wrote:
> Also, if interceptors are being added in the course of servicing a
> request, does one have to take special care of thread-safety
> issues? I understand the InterceptorProvider returns you a List by
> reference, not a copy, so you are free to add, delete, traverse
> elements, etc. But if you're in the context of a request, is there
> any mechanism to lock access to the interceptor list, so that
> someone else in your application with the same devious plan won't
> walk over the same data at the same time? Am I completely missing
> something about the architecture, here? It seems like modifying an
> interceptor list in flight has ConcurrentModification exceptions
> written all over it.
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 22 March 2007 21:04
> To: cxf-dev@incubator.apache.org
> Cc: cxf-user@incubator.apache.org
> Subject: Re: Programatically installing interceptors per
> (Bus|Service|Endpoint)
>
> On 3/22/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 21 March 2007 19:12
> > > To: cxf-dev@incubator.apache.org
> > > Cc: cxf-user@incubator.apache.org
> > > Subject: Re: Programatically installing interceptors per
> > > (Bus|Service|Endpoint)
> > >
> > > Also, I recently added an AbstractWSFeature class which
> I'd like to
> > > support the loading of a plugin for a particular
> scenario. The idea
> > > being that you can have a feature class - like a
> WSSecurityFeature -
> > > which configures your endpoint for something - like
> WS-Security. And
> > > it can just become part of the JAX-WS endpoint configuration. I
> > > posted some examples of how this might work in the
> client/EPR thread
> > > if you're interested. I'll be answering some of the
> questions that
> > > arose on that shortly...
> >
> >
> > This WSFeature stuff is interesting.
> >
> > One quick question, what would be the overlap between this and the
> > WS-Policy framework?
> >
> > I'm thinking specifically of the following policy use-case:
> > - policy assertion implies requirement on runtime
> > - corresponding AssertionBuilder indicates it has capability to
> > support this requirement
> > - corresponding PolicyInterceptorProvider contributes the necessary
> > interceptors to realize the capability in the dispatch chain
> > - dispatch-time policy verification ensures that this capability is
> > present as expected
> >
>
> Thats an interesting idea as well. I guess I don't fully grok
> all the policy stuff. But I'll check into and see if we can
> just use that instead. No need to replicate that.
>
> Do you think there would there be an issue if we don't have a
> policy schema for particular features?
Do you mean there not being a *standardized* policy schema for a
particular feature?
I guess in that case we could invent our own, or?
Nothing against the WS*Feature idea in principle ... but probably worth
thinking about a bit in terms of ensuring we don't end up with two
different means (WS*Feature and WS-Policy) to a similar end (asserting a
requirement on the runtime).
Cheers,
Eoghan
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 22 March 2007 21:04
> To: cxf-dev@incubator.apache.org
> Cc: cxf-user@incubator.apache.org
> Subject: Re: Programatically installing interceptors per
> (Bus|Service|Endpoint)
>
> On 3/22/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 21 March 2007 19:12
> > > To: cxf-dev@incubator.apache.org
> > > Cc: cxf-user@incubator.apache.org
> > > Subject: Re: Programatically installing interceptors per
> > > (Bus|Service|Endpoint)
> > >
> > > Also, I recently added an AbstractWSFeature class which
> I'd like to
> > > support the loading of a plugin for a particular
> scenario. The idea
> > > being that you can have a feature class - like a
> WSSecurityFeature -
> > > which configures your endpoint for something - like
> WS-Security. And
> > > it can just become part of the JAX-WS endpoint configuration. I
> > > posted some examples of how this might work in the
> client/EPR thread
> > > if you're interested. I'll be answering some of the
> questions that
> > > arose on that shortly...
> >
> >
> > This WSFeature stuff is interesting.
> >
> > One quick question, what would be the overlap between this and the
> > WS-Policy framework?
> >
> > I'm thinking specifically of the following policy use-case:
> > - policy assertion implies requirement on runtime
> > - corresponding AssertionBuilder indicates it has capability to
> > support this requirement
> > - corresponding PolicyInterceptorProvider contributes the necessary
> > interceptors to realize the capability in the dispatch chain
> > - dispatch-time policy verification ensures that this capability is
> > present as expected
> >
>
> Thats an interesting idea as well. I guess I don't fully grok
> all the policy stuff. But I'll check into and see if we can
> just use that instead. No need to replicate that.
>
> Do you think there would there be an issue if we don't have a
> policy schema for particular features?
Do you mean there not being a *standardized* policy schema for a
particular feature?
I guess in that case we could invent our own, or?
Nothing against the WS*Feature idea in principle ... but probably worth
thinking about a bit in terms of ensuring we don't end up with two
different means (WS*Feature and WS-Policy) to a similar end (asserting a
requirement on the runtime).
Cheers,
Eoghan
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/22/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 21 March 2007 19:12
> > To: cxf-dev@incubator.apache.org
> > Cc: cxf-user@incubator.apache.org
> > Subject: Re: Programatically installing interceptors per
> > (Bus|Service|Endpoint)
> >
> > Also, I recently added an AbstractWSFeature class which I'd
> > like to support the loading of a plugin for a particular
> > scenario. The idea being that you can have a feature class -
> > like a WSSecurityFeature - which configures your endpoint for
> > something - like WS-Security. And it can just become part of
> > the JAX-WS endpoint configuration. I posted some examples of
> > how this might work in the client/EPR thread if you're
> > interested. I'll be answering some of the questions that
> > arose on that shortly...
>
>
> This WSFeature stuff is interesting.
>
> One quick question, what would be the overlap between this and the
> WS-Policy framework?
>
> I'm thinking specifically of the following policy use-case:
> - policy assertion implies requirement on runtime
> - corresponding AssertionBuilder indicates it has capability to support
> this requirement
> - corresponding PolicyInterceptorProvider contributes the necessary
> interceptors to realize the capability in the dispatch chain
> - dispatch-time policy verification ensures that this capability is
> present as expected
>
Thats an interesting idea as well. I guess I don't fully grok all the policy
stuff. But I'll check into and see if we can just use that instead. No need
to replicate that.
Do you think there would there be an issue if we don't have a policy schema
for particular features?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/22/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 21 March 2007 19:12
> > To: cxf-dev@incubator.apache.org
> > Cc: cxf-user@incubator.apache.org
> > Subject: Re: Programatically installing interceptors per
> > (Bus|Service|Endpoint)
> >
> > Also, I recently added an AbstractWSFeature class which I'd
> > like to support the loading of a plugin for a particular
> > scenario. The idea being that you can have a feature class -
> > like a WSSecurityFeature - which configures your endpoint for
> > something - like WS-Security. And it can just become part of
> > the JAX-WS endpoint configuration. I posted some examples of
> > how this might work in the client/EPR thread if you're
> > interested. I'll be answering some of the questions that
> > arose on that shortly...
>
>
> This WSFeature stuff is interesting.
>
> One quick question, what would be the overlap between this and the
> WS-Policy framework?
>
> I'm thinking specifically of the following policy use-case:
> - policy assertion implies requirement on runtime
> - corresponding AssertionBuilder indicates it has capability to support
> this requirement
> - corresponding PolicyInterceptorProvider contributes the necessary
> interceptors to realize the capability in the dispatch chain
> - dispatch-time policy verification ensures that this capability is
> present as expected
>
Thats an interesting idea as well. I guess I don't fully grok all the policy
stuff. But I'll check into and see if we can just use that instead. No need
to replicate that.
Do you think there would there be an issue if we don't have a policy schema
for particular features?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 21 March 2007 19:12
> To: cxf-dev@incubator.apache.org
> Cc: cxf-user@incubator.apache.org
> Subject: Re: Programatically installing interceptors per
> (Bus|Service|Endpoint)
>
> Also, I recently added an AbstractWSFeature class which I'd
> like to support the loading of a plugin for a particular
> scenario. The idea being that you can have a feature class -
> like a WSSecurityFeature - which configures your endpoint for
> something - like WS-Security. And it can just become part of
> the JAX-WS endpoint configuration. I posted some examples of
> how this might work in the client/EPR thread if you're
> interested. I'll be answering some of the questions that
> arose on that shortly...
This WSFeature stuff is interesting.
One quick question, what would be the overlap between this and the
WS-Policy framework?
I'm thinking specifically of the following policy use-case:
- policy assertion implies requirement on runtime
- corresponding AssertionBuilder indicates it has capability to support
this requirement
- corresponding PolicyInterceptorProvider contributes the necessary
interceptors to realize the capability in the dispatch chain
- dispatch-time policy verification ensures that this capability is
present as expected
Cheers,
Eoghan
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
Okay, that's interesting, if I understand what you intend. Is the
idea that you install a feature on an endpoint (where the feature is
manifest as a bean), and under the covers, the feature assembles all
the pieces, in the correct order, etc? That's basically what I'm
after, but I need access to the endpoint, so that I can install
interceptors on that specific level of granularity. (Again, sort of
fumbling around in the dark here, as I am not omniscient vis a vis
CXF internals.)
I'm not sure how the XML config you posted in the email I'm
responding to is relevant, since I'm not trying to statically
configure an interceptor -- I want all that to be done under the
hood, by my FooFeature bean.
Thanks!
-Fred
On Mar 21, 2007, at 3:12 PM, Dan Diephouse wrote:
> Also, I recently added an AbstractWSFeature class which I'd like to
> support
> the loading of a plugin for a particular scenario. The idea being
> that you
> can have a feature class - like a WSSecurityFeature - which
> configures your
> endpoint for something - like WS-Security. And it can just become
> part of
> the JAX-WS endpoint configuration. I posted some examples of how
> this might
> work in the client/EPR thread if you're interested. I'll be
> answering some
> of the questions that arose on that shortly...
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
Okay, that's interesting, if I understand what you intend. Is the
idea that you install a feature on an endpoint (where the feature is
manifest as a bean), and under the covers, the feature assembles all
the pieces, in the correct order, etc? That's basically what I'm
after, but I need access to the endpoint, so that I can install
interceptors on that specific level of granularity. (Again, sort of
fumbling around in the dark here, as I am not omniscient vis a vis
CXF internals.)
I'm not sure how the XML config you posted in the email I'm
responding to is relevant, since I'm not trying to statically
configure an interceptor -- I want all that to be done under the
hood, by my FooFeature bean.
Thanks!
-Fred
On Mar 21, 2007, at 3:12 PM, Dan Diephouse wrote:
> Also, I recently added an AbstractWSFeature class which I'd like to
> support
> the loading of a plugin for a particular scenario. The idea being
> that you
> can have a feature class - like a WSSecurityFeature - which
> configures your
> endpoint for something - like WS-Security. And it can just become
> part of
> the JAX-WS endpoint configuration. I posted some examples of how
> this might
> work in the client/EPR thread if you're interested. I'll be
> answering some
> of the questions that arose on that shortly...
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 21 March 2007 19:12
> To: cxf-dev@incubator.apache.org
> Cc: cxf-user@incubator.apache.org
> Subject: Re: Programatically installing interceptors per
> (Bus|Service|Endpoint)
>
> Also, I recently added an AbstractWSFeature class which I'd
> like to support the loading of a plugin for a particular
> scenario. The idea being that you can have a feature class -
> like a WSSecurityFeature - which configures your endpoint for
> something - like WS-Security. And it can just become part of
> the JAX-WS endpoint configuration. I posted some examples of
> how this might work in the client/EPR thread if you're
> interested. I'll be answering some of the questions that
> arose on that shortly...
This WSFeature stuff is interesting.
One quick question, what would be the overlap between this and the
WS-Policy framework?
I'm thinking specifically of the following policy use-case:
- policy assertion implies requirement on runtime
- corresponding AssertionBuilder indicates it has capability to support
this requirement
- corresponding PolicyInterceptorProvider contributes the necessary
interceptors to realize the capability in the dispatch chain
- dispatch-time policy verification ensures that this capability is
present as expected
Cheers,
Eoghan
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Dan Diephouse <da...@envoisolutions.com>.
I just added some ways to specify interceptors for your endpoint or proxy:
<jaxws:endpoint id="epWithInterceptors"
implementor="org.apache.cxf.jaxws.service.Hello"
address="http://localhost:8080/test">
<jaxws:inInterceptors>
<bean class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
</jaxws:inInterceptors>
<jaxws:outInterceptors>
<bean class="org.apache.cxf.interceptor.LoggingOutInterceptor"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
</jaxws:outInterceptors>
</jaxws:endpoint>
Or on the client side (which I don't have fancy spring 2.0 support for yet)
<bean id="proxyFactory" class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">
<property name="address" value="http://endpoint/url"/>
<property name="serviceClass" value="myServiceInterface"/>
<property name="inInterceptors">
<list>
<bean class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
</list>
</property>
</bean>
Also, I recently added an AbstractWSFeature class which I'd like to support
the loading of a plugin for a particular scenario. The idea being that you
can have a feature class - like a WSSecurityFeature - which configures your
endpoint for something - like WS-Security. And it can just become part of
the JAX-WS endpoint configuration. I posted some examples of how this might
work in the client/EPR thread if you're interested. I'll be answering some
of the questions that arose on that shortly...
- Dan
On 3/21/07, Fred Dushin <fr...@dushin.net> wrote:
>
> Thank you, Jervis and Andrea.
>
> I think probably the last part of Andrea's response comes closest to
> the sort of thing I need:
>
> > You can also have an interceptor installed at bus level which, when
> > executing, adds further interceptors to the chain, possibly on a
> > per message basis. This is done for example in
> > org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
>
> (Jervis, I see what the code you referenced is doing, but does an
> ordinary developer like myself have a hook into the creation of an
> Endpoint? The code you reference seems to be a special case of
> installing a BindingFactory into an Endpoint, which is part of the
> CXF plumbing. I'm looking for something more in userland, as they
> say. Unless I'm missing something -- please correct me if I am.)
>
> The issue is that I want to programatically install these
> interceptors from plugin (i.e., spring-loaded) code, but it looks
> like there's really no way to do that. Andrea's solution (if I
> understand it -- apologies if I'm being thick) is to install an
> interceptor during the servicing of a request, which works, though
> I'd hoped I could avoid that sort of overhead -- it's something I
> really only need to do once, at the point at which the operative
> InterceptorProvider is being set-up or established.
>
> Also, if interceptors are being added in the course of servicing a
> request, does one have to take special care of thread-safety issues?
> I understand the InterceptorProvider returns you a List by reference,
> not a copy, so you are free to add, delete, traverse elements, etc.
> But if you're in the context of a request, is there any mechanism to
> lock access to the interceptor list, so that someone else in your
> application with the same devious plan won't walk over the same data
> at the same time? Am I completely missing something about the
> architecture, here? It seems like modifying an interceptor list in
> flight has ConcurrentModification exceptions written all over it.
>
> Thanks,
> -Fred
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Dan Diephouse <da...@envoisolutions.com>.
I just added some ways to specify interceptors for your endpoint or proxy:
<jaxws:endpoint id="epWithInterceptors"
implementor="org.apache.cxf.jaxws.service.Hello"
address="http://localhost:8080/test">
<jaxws:inInterceptors>
<bean class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
</jaxws:inInterceptors>
<jaxws:outInterceptors>
<bean class="org.apache.cxf.interceptor.LoggingOutInterceptor"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
</jaxws:outInterceptors>
</jaxws:endpoint>
Or on the client side (which I don't have fancy spring 2.0 support for yet)
<bean id="proxyFactory" class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">
<property name="address" value="http://endpoint/url"/>
<property name="serviceClass" value="myServiceInterface"/>
<property name="inInterceptors">
<list>
<bean class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
</list>
</property>
</bean>
Also, I recently added an AbstractWSFeature class which I'd like to support
the loading of a plugin for a particular scenario. The idea being that you
can have a feature class - like a WSSecurityFeature - which configures your
endpoint for something - like WS-Security. And it can just become part of
the JAX-WS endpoint configuration. I posted some examples of how this might
work in the client/EPR thread if you're interested. I'll be answering some
of the questions that arose on that shortly...
- Dan
On 3/21/07, Fred Dushin <fr...@dushin.net> wrote:
>
> Thank you, Jervis and Andrea.
>
> I think probably the last part of Andrea's response comes closest to
> the sort of thing I need:
>
> > You can also have an interceptor installed at bus level which, when
> > executing, adds further interceptors to the chain, possibly on a
> > per message basis. This is done for example in
> > org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
>
> (Jervis, I see what the code you referenced is doing, but does an
> ordinary developer like myself have a hook into the creation of an
> Endpoint? The code you reference seems to be a special case of
> installing a BindingFactory into an Endpoint, which is part of the
> CXF plumbing. I'm looking for something more in userland, as they
> say. Unless I'm missing something -- please correct me if I am.)
>
> The issue is that I want to programatically install these
> interceptors from plugin (i.e., spring-loaded) code, but it looks
> like there's really no way to do that. Andrea's solution (if I
> understand it -- apologies if I'm being thick) is to install an
> interceptor during the servicing of a request, which works, though
> I'd hoped I could avoid that sort of overhead -- it's something I
> really only need to do once, at the point at which the operative
> InterceptorProvider is being set-up or established.
>
> Also, if interceptors are being added in the course of servicing a
> request, does one have to take special care of thread-safety issues?
> I understand the InterceptorProvider returns you a List by reference,
> not a copy, so you are free to add, delete, traverse elements, etc.
> But if you're in the context of a request, is there any mechanism to
> lock access to the interceptor list, so that someone else in your
> application with the same devious plan won't walk over the same data
> at the same time? Am I completely missing something about the
> architecture, here? It seems like modifying an interceptor list in
> flight has ConcurrentModification exceptions written all over it.
>
> Thanks,
> -Fred
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
Answering my own question here, after consultation with some CXF devs.
The anwser is, the lists returned from interceptors are returned from
the InterceptorProviders can and should be thread-safe, but it's a
current limitation that they are not. I've submitted https://
issues.apache.org/jira/browse/CXF-480 and am running the build on a
patch, which I'll submit shortly.
This still does not mean that one is completely out of the woods --
concurrent access to the interceptor list is safe, but you are still
not guaranteed that another thread hasn't already added (or removed)
an interceptor you may be looking for as you traverse it.
In my particular case, this should not be an issue, since I have
control over which interceptor (types) I am looking for and
inserting, but buyer beware, in the general case.
I suppose a general pattern we might adopt and urge on applications
is to acquire a lock on the list, itself, whilst traversing and
inserting or removing elements, e.g.,
synchronized(interceptorList) {
// look for the interceptor I want to add
// if it's not there, add it
// leave a breadcrumb so I know I already inserted it
}
That sort of thing. Not sure what else can be said, other than a C++-
style ::insert.
Someone else mentioned that it might be nice to have he notion of an
interceptor id, which I'd fully agree with, so that you could do a
lookup by id. Your interceptor lists are then just (sortable) maps
(or multimaps, as the case may be), and lookup can be done in O(lg
n). But that's a pretty disruptive change to the whole
architecture. OTOH, better to do it now than once the cat is out of
the bag...
-Fred
On Mar 21, 2007, at 5:48 AM, Fred Dushin wrote:
> Also, if interceptors are being added in the course of servicing a
> request, does one have to take special care of thread-safety
> issues? I understand the InterceptorProvider returns you a List by
> reference, not a copy, so you are free to add, delete, traverse
> elements, etc. But if you're in the context of a request, is there
> any mechanism to lock access to the interceptor list, so that
> someone else in your application with the same devious plan won't
> walk over the same data at the same time? Am I completely missing
> something about the architecture, here? It seems like modifying an
> interceptor list in flight has ConcurrentModification exceptions
> written all over it.
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
Thank you, Jervis and Andrea.
I think probably the last part of Andrea's response comes closest to
the sort of thing I need:
> You can also have an interceptor installed at bus level which, when
> executing, adds further interceptors to the chain, possibly on a
> per message basis. This is done for example in
> org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
(Jervis, I see what the code you referenced is doing, but does an
ordinary developer like myself have a hook into the creation of an
Endpoint? The code you reference seems to be a special case of
installing a BindingFactory into an Endpoint, which is part of the
CXF plumbing. I'm looking for something more in userland, as they
say. Unless I'm missing something -- please correct me if I am.)
The issue is that I want to programatically install these
interceptors from plugin (i.e., spring-loaded) code, but it looks
like there's really no way to do that. Andrea's solution (if I
understand it -- apologies if I'm being thick) is to install an
interceptor during the servicing of a request, which works, though
I'd hoped I could avoid that sort of overhead -- it's something I
really only need to do once, at the point at which the operative
InterceptorProvider is being set-up or established.
Also, if interceptors are being added in the course of servicing a
request, does one have to take special care of thread-safety issues?
I understand the InterceptorProvider returns you a List by reference,
not a copy, so you are free to add, delete, traverse elements, etc.
But if you're in the context of a request, is there any mechanism to
lock access to the interceptor list, so that someone else in your
application with the same devious plan won't walk over the same data
at the same time? Am I completely missing something about the
architecture, here? It seems like modifying an interceptor list in
flight has ConcurrentModification exceptions written all over it.
Thanks,
-Fred
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Fred Dushin <fr...@dushin.net>.
Thank you, Jervis and Andrea.
I think probably the last part of Andrea's response comes closest to
the sort of thing I need:
> You can also have an interceptor installed at bus level which, when
> executing, adds further interceptors to the chain, possibly on a
> per message basis. This is done for example in
> org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
(Jervis, I see what the code you referenced is doing, but does an
ordinary developer like myself have a hook into the creation of an
Endpoint? The code you reference seems to be a special case of
installing a BindingFactory into an Endpoint, which is part of the
CXF plumbing. I'm looking for something more in userland, as they
say. Unless I'm missing something -- please correct me if I am.)
The issue is that I want to programatically install these
interceptors from plugin (i.e., spring-loaded) code, but it looks
like there's really no way to do that. Andrea's solution (if I
understand it -- apologies if I'm being thick) is to install an
interceptor during the servicing of a request, which works, though
I'd hoped I could avoid that sort of overhead -- it's something I
really only need to do once, at the point at which the operative
InterceptorProvider is being set-up or established.
Also, if interceptors are being added in the course of servicing a
request, does one have to take special care of thread-safety issues?
I understand the InterceptorProvider returns you a List by reference,
not a copy, so you are free to add, delete, traverse elements, etc.
But if you're in the context of a request, is there any mechanism to
lock access to the interceptor list, so that someone else in your
application with the same devious plan won't walk over the same data
at the same time? Am I completely missing something about the
architecture, here? It seems like modifying an interceptor list in
flight has ConcurrentModification exceptions written all over it.
Thanks,
-Fred
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Andrea Smyth <an...@iona.com>.
Fred Dushin wrote:
> I understand that CXF provides APIs for installed interceptors
> through the InterceptorProvider interface, which the Bus, Endpoint,
> and Service types all extend (among other types).
>
> Suppose I want to create, via configuration, some sort of CXF plugin
> (I hesitate to call this an interceptor, for reasons which should
> become obvious). The purpose of this plugin is to install
> interceptors programatically into the call chain.
>
> I can see how to do this using a reference to a Bus -- e.g., I can
> spring-load the plugin I want to install, and wire it up to the Bus
> -- common pattern. And from there, I can get access to the Bus-level
> InterceptorProvider, since the Bus extends that type.
>
> That would work in the case where I want my plugin to install these
> interceptors globally, i.e, for all services and endpoints in a Bus;
> however, suppose I want to install my interceptors at a finer level
> of granularity, e.g., per endpoint. Is there a way for my plugin,
> which seems to be loaded at Bus initialization time, to get a handle
> on the Service or Endpoint (which also implement InterceptorProvider)
> for which it is (or counterfactually would be) configured? Is this
> an envisioned pattern? Or is there some other sort of interceptor I
> don't know of, e.g, which hooks into Service or Endpoint creation?
>
> Thanks!
> -Fred
Hi Fred,
On the client side you can manage interceptors at the client, endpoint,
service and bus level. If you have created your proxy using JAXWS APIs,
you need to first obtain a reference to the underlying CXF client object
as follows:
BasicGreeterService gs = new BasicGreeterService();
Greeter greeter = gs.getGreeterPort();
org.apache.cxf.endpoint.Client client =
org.apache.cxf.frontend.ClientProxy.getClient(greeter);
client.getOutInterceptors().add(...);
org.apache.cxf.endpoint.Endpoint endpoint = client.getEndpoint();
endpoint.getOutInterceptors().add(...);
org.apache.cxf.service.Service service = endpoint.getService();
service.getOutInterceptors().add(...);
On the server side, if you use the JAXWS API, cast the
javax.xml.ws.Endpoint object you obtained from publish to get access to
its underlying CXF endpoint. Note that Server - unlike Client - is not
an interceptor provider, which is a bit asymmetric.
javax.xml.ws.Endpoint jaxwsEndpoint =
javax.xml.ws.Endpoint.publish("http://localhost:9020/SoapContext/GreeterPort",
new GreeterImpl(););
LoggingOutInterceptor out = new LoggingOutInterceptor();
org.apache.cxf.jaxws.EndpointImpl jaxwsEndpointImpl =
(org.apache.cxf.jaxws.EndpointImpl)endpoint;
org.apache.cxf.endpoint.Server server = jaxwsEndpointImpl.getServer();
org.apache.cxf.endpoint.Endpoint endpoint = server.getEndpoint();
endpoint.getOutInterceptors().add(...);
org.apache.cxf.service.Service service = endpoint.getService();
service.getOutInterceptors().add(...);
You can also have an interceptor installed at bus level which, when
executing, adds further interceptors to the chain, possibly on a per
message basis. This is done for example in
org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
Cheers,
Andrea.
Re: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by Andrea Smyth <an...@iona.com>.
Fred Dushin wrote:
> I understand that CXF provides APIs for installed interceptors
> through the InterceptorProvider interface, which the Bus, Endpoint,
> and Service types all extend (among other types).
>
> Suppose I want to create, via configuration, some sort of CXF plugin
> (I hesitate to call this an interceptor, for reasons which should
> become obvious). The purpose of this plugin is to install
> interceptors programatically into the call chain.
>
> I can see how to do this using a reference to a Bus -- e.g., I can
> spring-load the plugin I want to install, and wire it up to the Bus
> -- common pattern. And from there, I can get access to the Bus-level
> InterceptorProvider, since the Bus extends that type.
>
> That would work in the case where I want my plugin to install these
> interceptors globally, i.e, for all services and endpoints in a Bus;
> however, suppose I want to install my interceptors at a finer level
> of granularity, e.g., per endpoint. Is there a way for my plugin,
> which seems to be loaded at Bus initialization time, to get a handle
> on the Service or Endpoint (which also implement InterceptorProvider)
> for which it is (or counterfactually would be) configured? Is this
> an envisioned pattern? Or is there some other sort of interceptor I
> don't know of, e.g, which hooks into Service or Endpoint creation?
>
> Thanks!
> -Fred
Hi Fred,
On the client side you can manage interceptors at the client, endpoint,
service and bus level. If you have created your proxy using JAXWS APIs,
you need to first obtain a reference to the underlying CXF client object
as follows:
BasicGreeterService gs = new BasicGreeterService();
Greeter greeter = gs.getGreeterPort();
org.apache.cxf.endpoint.Client client =
org.apache.cxf.frontend.ClientProxy.getClient(greeter);
client.getOutInterceptors().add(...);
org.apache.cxf.endpoint.Endpoint endpoint = client.getEndpoint();
endpoint.getOutInterceptors().add(...);
org.apache.cxf.service.Service service = endpoint.getService();
service.getOutInterceptors().add(...);
On the server side, if you use the JAXWS API, cast the
javax.xml.ws.Endpoint object you obtained from publish to get access to
its underlying CXF endpoint. Note that Server - unlike Client - is not
an interceptor provider, which is a bit asymmetric.
javax.xml.ws.Endpoint jaxwsEndpoint =
javax.xml.ws.Endpoint.publish("http://localhost:9020/SoapContext/GreeterPort",
new GreeterImpl(););
LoggingOutInterceptor out = new LoggingOutInterceptor();
org.apache.cxf.jaxws.EndpointImpl jaxwsEndpointImpl =
(org.apache.cxf.jaxws.EndpointImpl)endpoint;
org.apache.cxf.endpoint.Server server = jaxwsEndpointImpl.getServer();
org.apache.cxf.endpoint.Endpoint endpoint = server.getEndpoint();
endpoint.getOutInterceptors().add(...);
org.apache.cxf.service.Service service = endpoint.getService();
service.getOutInterceptors().add(...);
You can also have an interceptor installed at bus level which, when
executing, adds further interceptors to the chain, possibly on a per
message basis. This is done for example in
org.apache.cxf.ws.policy.ClientPolicyOutInterceptor.
Cheers,
Andrea.
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Fred,
Not sure if I understand your question correctly. If what you want is to instantiate and install interceptors per service/endpoint/binding, for example, you may have a strategy that can load different interceptors depending on a specific binding property, yes surely you can do this. SoapBindingFactory.java shows how SOAP binding specific interceptors are loaded.
Cheers,
Jervis
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 2007?3?21? 5:02
> To: cxf-user@incubator.apache.org; cxf-dev@incubator.apache.org
> Subject: Programatically installing interceptors per
> (Bus|Service|Endpoint)
>
>
> I understand that CXF provides APIs for installed interceptors
> through the InterceptorProvider interface, which the Bus, Endpoint,
> and Service types all extend (among other types).
>
> Suppose I want to create, via configuration, some sort of CXF plugin
> (I hesitate to call this an interceptor, for reasons which should
> become obvious). The purpose of this plugin is to install
> interceptors programatically into the call chain.
>
> I can see how to do this using a reference to a Bus -- e.g., I can
> spring-load the plugin I want to install, and wire it up to the Bus
> -- common pattern. And from there, I can get access to the
> Bus-level
> InterceptorProvider, since the Bus extends that type.
>
> That would work in the case where I want my plugin to install these
> interceptors globally, i.e, for all services and endpoints in
> a Bus;
> however, suppose I want to install my interceptors at a finer level
> of granularity, e.g., per endpoint. Is there a way for my plugin,
> which seems to be loaded at Bus initialization time, to get a handle
> on the Service or Endpoint (which also implement
> InterceptorProvider)
> for which it is (or counterfactually would be) configured? Is this
> an envisioned pattern? Or is there some other sort of interceptor I
> don't know of, e.g, which hooks into Service or Endpoint creation?
>
> Thanks!
> -Fred
>
RE: Programatically installing interceptors per (Bus|Service|Endpoint)
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Fred,
Not sure if I understand your question correctly. If what you want is to instantiate and install interceptors per service/endpoint/binding, for example, you may have a strategy that can load different interceptors depending on a specific binding property, yes surely you can do this. SoapBindingFactory.java shows how SOAP binding specific interceptors are loaded.
Cheers,
Jervis
> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net]
> Sent: 2007?3?21? 5:02
> To: cxf-user@incubator.apache.org; cxf-dev@incubator.apache.org
> Subject: Programatically installing interceptors per
> (Bus|Service|Endpoint)
>
>
> I understand that CXF provides APIs for installed interceptors
> through the InterceptorProvider interface, which the Bus, Endpoint,
> and Service types all extend (among other types).
>
> Suppose I want to create, via configuration, some sort of CXF plugin
> (I hesitate to call this an interceptor, for reasons which should
> become obvious). The purpose of this plugin is to install
> interceptors programatically into the call chain.
>
> I can see how to do this using a reference to a Bus -- e.g., I can
> spring-load the plugin I want to install, and wire it up to the Bus
> -- common pattern. And from there, I can get access to the
> Bus-level
> InterceptorProvider, since the Bus extends that type.
>
> That would work in the case where I want my plugin to install these
> interceptors globally, i.e, for all services and endpoints in
> a Bus;
> however, suppose I want to install my interceptors at a finer level
> of granularity, e.g., per endpoint. Is there a way for my plugin,
> which seems to be loaded at Bus initialization time, to get a handle
> on the Service or Endpoint (which also implement
> InterceptorProvider)
> for which it is (or counterfactually would be) configured? Is this
> an envisioned pattern? Or is there some other sort of interceptor I
> don't know of, e.g, which hooks into Service or Endpoint creation?
>
> Thanks!
> -Fred
>