You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ravi Luthra <co...@gmail.com> on 2010/07/09 23:12:41 UTC
dynamic policy on endpoints (not clients)?
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.
Thanks,
Ravi
Re: dynamic policy on endpoints (not clients)?
Posted by Glen Mazza <gl...@gmail.com>.
The WSS4J interceptors (https://cwiki.apache.org/CXF20DOC/ws-security.html)
are not automatically activated if you're using WS-Policy/WS-Security
Policy--different interceptors are used there. So you'll need to explicitly
attach the WSS4J policy interceptors to your client and/or service if you
want them to activate.
Glen
Ravi Luthra wrote:
>
> 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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/dynamic-policy-on-endpoints-not-clients-tp1045717p1046875.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: dynamic policy on endpoints (not clients)?
Posted by Ravi Luthra <co...@gmail.com>.
I eventually got it to work, but I think in the non-easy way you described.
I wiped out the policyEngineImpl's endpoint policy (the cached one) with a
null, and also created a PolicyProvider that pushes out the correct policy
at runtime. I've been trying to replace the policy on the endpoint during
the "In" time. I did notice that the policyininterceptor only looks at the
policy override if the "isRequestor" is true. I think that means policy
computation for clients on the response, but I am not sure.
Anyway here is the working code in case anyone finds it helpful:
private void setPolicyOnEndpoint(final Document originalWsdl,
final EndpointImpl e) throws TransformerException,
TransformerConfigurationException,
TransformerFactoryConfigurationError {
final Bus bus = e.getBus();
final PolicyBuilder pb = bus.getExtension(PolicyBuilder.class);
final Document modifiedWsdl = processPolicyChanges(originalWsdl);
TransformerFactory.newInstance().newTransformer().transform(
new DOMSource(modifiedWsdl), new StreamResult(System.out));
final NodeList elems = modifiedWsdl.getElementsByTagNameNS(
PolicyInjector.NS_POLICY, PolicyInjector.ELEM_POLICY);
if (elems.getLength() > 0) {
final Element policyElement = (Element) elems.item(0);
final Policy policy = pb.getPolicy(policyElement);
final EndpointInfo ei = e.getServer().getEndpoint()
.getEndpointInfo();
policyMap.put(ei, policy);
final PolicyEngineImpl pole = (PolicyEngineImpl) bus
.getExtension(PolicyEngine.class);
addPolicyProvider(pole);
final Destination d = e.getServer().getDestination();
// Wipe out the cached policy so it can be recomputed
pole.setServerEndpointPolicy(ei, null);
}
}
/**
* Adds a policy provider so that custom runtime-policies can be added
*
* @param pole
*/
private void addPolicyProvider(final PolicyEngineImpl pole) {
for (final PolicyProvider pp : pole.getPolicyProviders()) {
if (pp.getClass().equals(CXFRuntimePolicyProvider.class)) {
return;
}
}
pole.getPolicyProviders().add(new CXFRuntimePolicyProvider());
}
private static final Map<EndpointInfo, Policy> policyMap = new
IdentityHashMap<EndpointInfo, Policy>();
private class CXFRuntimePolicyProvider implements PolicyProvider {
@Override
public Policy getEffectivePolicy(ServiceInfo si) {
return null;
}
@Override
public Policy getEffectivePolicy(EndpointInfo ei) {
return policyMap.get(ei);
}
@Override
public Policy getEffectivePolicy(BindingOperationInfo bi) {
return null;
}
@Override
public Policy getEffectivePolicy(BindingMessageInfo bmi) {
return null;
}
@Override
public Policy getEffectivePolicy(BindingFaultInfo bfi) {
return null;
}
}
CXF gives way more control on policy than other stacks (like Metro) which is
very nice. With CXF policy change is on the fly. I am still interested in
policy override so that I can do per-IP address, or perhaps request
parameter based policy decisions.
weAs far as a simple example, I'm using JBoss's CXF integration package, so
for my own sanity if I were to get you a sample, it would be tied to JBoss
and it's CXF integration pattern. I'll see what I can do next week.
Thanks,
Ravi
On Thu, Jul 15, 2010 at 2:10 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday 13 July 2010 11:24:51 am Ravi Luthra wrote:
> > 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?
>
> Is this on the "in" or the "out" side. That would give me a place to
> look.
>
> Any chance you can create a simple example? Something with a simple
> policy
> would be great. :-)
>
> Dan
>
>
> >
> > Thanks
> > Ravi
> >
> > On Sat, Jul 10, 2010 at 8:01 PM, Daniel Kulp <dk...@apache.org> 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
> > > dkulp@apache.org
> > > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: dynamic policy on endpoints (not clients)?
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 13 July 2010 11:24:51 am Ravi Luthra wrote:
> 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?
Is this on the "in" or the "out" side. That would give me a place to look.
Any chance you can create a simple example? Something with a simple policy
would be great. :-)
Dan
>
> Thanks
> Ravi
>
> On Sat, Jul 10, 2010 at 8:01 PM, Daniel Kulp <dk...@apache.org> 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
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: dynamic policy on endpoints (not clients)?
Posted by Ravi Luthra <co...@gmail.com>.
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 <dk...@apache.org> 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
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: dynamic policy on endpoints (not clients)?
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog
Re: dynamic policy on endpoints (not clients)?
Posted by Glen Mazza <gl...@gmail.com>.
http://www.jroller.com/gmazza/entry/jaxwshandlers_to_cxfinterceptors perhaps.
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.
>
> Thanks,
> Ravi
>
--
View this message in context: http://cxf.547215.n5.nabble.com/dynamic-policy-on-endpoints-not-clients-tp1045717p1045756.html
Sent from the cxf-user mailing list archive at Nabble.com.