I've just tried the easy way, but I'm finding that the policy I've set
(using the policy builder getting a Policy neethi object) isn't being
respected after that. I think it has something to do with the WSSJ policy
interceptor not running. Could this be my problem?

Thanks
Ravi

On Sat, Jul 10, 2010 at 8:01 PM, Daniel Kulp <[email protected]> wrote:

> On Friday 09 July 2010 5:12:41 pm Ravi Luthra wrote:
> > Does anyone know how to dynamically adjust a running endpoint's policy on
> > the fly, at runtime, without restarting anything in CXF? We have a DOM
> tree
> > of the policy, but don't know what kind of interceptors, or actions to
> > write. We don't want to modify the source of CXF, but just leverage its
> > pluggability.
>
> It's doable, but it's going to be a bit tricky.   The effective policies
> are
> cached all over the place, so if a policy changes, you also need to walk
> through the various places and clear out caches.
>
> There really are two options:
>
> 1) (hard, but complete control) - from an interceptor or something, you
> would
> replace the DOM of the policy on the appropriate place (Service, Endpoint,
> Operation, etc...)   Really, just wrapper the DOM element with an
> UnknownExtensibilityElement and add that as an extensor onto the
> appropriate
> place.   You would then need to clear the caches.   For that, you would be
> best to look at the code for the PolicyEngineImpl to get the keys for the
> various caches and the places they are used.   The PolicyIn/OutInterceptors
> would recalc the next time they are hit.
>
> 2) Easy - if you are setting your policy in an interceptor that would run
> BEFORE the PolicyIn/OutInterceptors, you can build your own Policy object
> (get
> the PolicyBuilder extension from the Bus and call it's getPolicy methods),
> you
> can set that Policy object on the message using the
> PolicyConstants.POLICY_OVERRIDE key.
>
> Dan
>
> >
> > Thanks,
> > Ravi
>
> --
> Daniel Kulp
> [email protected]
> http://dankulp.com/blog
>

Reply via email to