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 2008/08/07 21:25:31 UTC
Server Response Policy
I'm having trouble with the CXF policy framework, which is causing a
little bit of grief. I think this is a developer, as opposed to a
user issue, as I /think/ it points to a bug in the policy framework.
If not, I can migrate the conversation to the users list.
What I'm finding is that a CXF server that has policy defined at the
endpoint (I'm using the CXF policy feature, whereby you can reference
a WS-Policy expression in Spring) is effectively treating the
operative policy in the server on the outbound interceptor chain the
same way as it does on the inbound interceptor chain.
Let me be more concrete. Assume the following config fragment in
Spring:
<jaxws:endpoint ... >
<jaxws:features>
<cxfp:policies>
<wsp:PolicyReference URI="#MyPolicy"/>
</cxfp:policies>
</jaxws:features>
</jaxws:endpoint>
...
<wsp:Policy wsu:Id="MyPolicy">
...
</wsp:Policy>
So on the inbound server side, I definitely get this as the effective
policy, and I can do policy enforcement by setting the asserted flag
on various assertions selected (in the case of inbound server,
everything is selected). Note that I have interceptors installed in
the runtime to do this enforcement.
However, on the outbound response, I'm getting the same effective
policy, and I can see how it's getting set -- precisely in the
following stacktrace (pardon the wrap):
Thread [btpool2-1] (Suspended)
InitializingPolicyEngine
(PolicyEngineImpl).getEndpointPolicy(EndpointInfo, EndpointPolicy,
boolean, Assertor) line: 220
InitializingPolicyEngine
(PolicyEngineImpl).getServerEndpointPolicy(EndpointInfo, Destination)
line: 214
EffectivePolicyImpl.initialisePolicy(EndpointInfo,
BindingOperationInfo, PolicyEngineImpl, boolean) line: 101
EffectivePolicyImpl.initialise(EndpointInfo, BindingOperationInfo,
PolicyEngineImpl, Assertor, boolean) line: 79
InitializingPolicyEngine
(PolicyEngineImpl).getEffectiveServerResponsePolicy(EndpointInfo,
BindingOperationInfo, Destination) line: 171
ServerPolicyOutInterceptor.handle(Message) line: 77
ServerPolicyOutInterceptor
(AbstractPolicyInterceptor).handleMessage(Message) line: 56
PhaseInterceptorChain.doIntercept(Message) line: 221
OutgoingChainInterceptor.handleMessage(Message) line: 74
PhaseInterceptorChain.doIntercept(Message) line: 221
ChainInitiationObserver.onMessage(Message) line: 78
JettyHTTPDestination.serviceRequest(ServletContext,
HttpServletRequest, HttpServletResponse) line: 278
JettyHTTPDestination.doService(ServletContext, HttpServletRequest,
HttpServletResponse) line: 252
JettyHTTPHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 70
ContextHandler.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 726
ContextHandlerCollection.handle(String, HttpServletRequest,
HttpServletResponse, int) line: 206
Server(HandlerWrapper).handle(String, HttpServletRequest,
HttpServletResponse, int) line: 152
Server.handle(HttpConnection) line: 324
HttpConnection.handleRequest() line: 505
HttpConnection$RequestHandler.content(Buffer) line: 842
HttpParser.parseNext() line: 730
HttpParser.parseAvailable() line: 205
HttpConnection.handle() line: 380
SslSocketConnector$SslConnection(SocketConnector$Connection).run()
line: 228
SslSocketConnector$SslConnection.run() line: 620
BoundedThreadPool$PoolThread.run() line: 450
But in this case, there are no interceptors installed in the response
interceptor chain. As a consequence, the request "fails" (in a manner
described below) with a "None of the policy alternatives can be
satisfied" message, which is set in the
PolicyVerificationOutInterceptor.
Note, however, that the SOAP:Fault is actually embedded in the response:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<sayHiResponse xmlns="http://acme.com/greeter/types">
<responseType>Bonjour tony</responseType>
</sayHiResponse>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>None of the policy alternatives can be
satisfied.</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Oops. Something seems awry with the phase in which the fault is
written.
But regardless, should the effective policy on the response be the
same as the effective policy on the request? Or should policy
assertion implementors code their interceptors to handle the response
chain, as well as the request?
-Fred
Re: Server Response Policy
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I reckon it would be useful if it were possible to explicitly state in the CXF WS-Policy feature that a given policy
expression is inbound/outbound only.
Perhaps another option is to provide reusable policy interceptors which could simply (and blindly) assert some policies using
preconfigured custom policy namespaces (ex : get an AssertionInfo matching a configured policy namespace and assert it), such that
such interceptors can be reused in cases whereby it does not make much sense to enforce some policies on the inbound or outbound
chain...
Cheers, Sergey
> Well I can definitely work around the problem, just by configuring my interceptors to check off the same assertions on the
> outbound side. This requires though, that I stick a reference to some request state information on the exchange, and that I
> ensure that an OutInterceptor is installed before between the policy interceptors on the outbound side.
>
> My solution seems a little hokey to me -- I'd rather that the AssertionInfo objects I've already ticked off as asserted be the
> same instances on the response channel, but that's not the case (I have not looked yet to see where a copy of the
> AssertionInfoMap is made -- maybe that's the real issue here, as opposed to the same effective policy on the inbound and
> outbound sides).
>
> -Fred
>
> On Aug 8, 2008, at 11:55 AM, Daniel Kulp wrote:
>
>> Hmm.. I'm not really sure, but this MAY be correct behavior.
>>
>> I'm thinking something like the MTOM policy. For that, there has to be
>> something on the outgoing side to see if the MTOM policy is there and turn on
>> MTOM if so.
>>
>> It's somewhat like some policies are "enforced" on the incoming chain,
>> and "configured" on the outgoing chains. Thus, the policy should be able to
>> handle both sides of that.
>>
>> Dan
>>
>>
>>
>> On Thursday 07 August 2008 3:25:31 pm Fred Dushin wrote:
>>> I'm having trouble with the CXF policy framework, which is causing a
>>> little bit of grief. I think this is a developer, as opposed to a
>>> user issue, as I /think/ it points to a bug in the policy framework.
>>> If not, I can migrate the conversation to the users list.
>>>
>>> What I'm finding is that a CXF server that has policy defined at the
>>> endpoint (I'm using the CXF policy feature, whereby you can reference
>>> a WS-Policy expression in Spring) is effectively treating the
>>> operative policy in the server on the outbound interceptor chain the
>>> same way as it does on the inbound interceptor chain.
>>>
>>> Let me be more concrete. Assume the following config fragment in
>>> Spring:
>>>
>>> <jaxws:endpoint ... >
>>> <jaxws:features>
>>> <cxfp:policies>
>>> <wsp:PolicyReference URI="#MyPolicy"/>
>>> </cxfp:policies>
>>> </jaxws:features>
>>> </jaxws:endpoint>
>>> ...
>>> <wsp:Policy wsu:Id="MyPolicy">
>>> ...
>>> </wsp:Policy>
>>>
>>> So on the inbound server side, I definitely get this as the effective
>>> policy, and I can do policy enforcement by setting the asserted flag
>>> on various assertions selected (in the case of inbound server,
>>> everything is selected). Note that I have interceptors installed in
>>> the runtime to do this enforcement.
>>>
>>> However, on the outbound response, I'm getting the same effective
>>> policy, and I can see how it's getting set -- precisely in the
>>> following stacktrace (pardon the wrap):
>>>
>>> Thread [btpool2-1] (Suspended)
>>>
>>> InitializingPolicyEngine
>>> (PolicyEngineImpl).getEndpointPolicy(EndpointInfo, EndpointPolicy,
>>> boolean, Assertor) line: 220
>>>
>>> InitializingPolicyEngine
>>> (PolicyEngineImpl).getServerEndpointPolicy(EndpointInfo, Destination)
>>> line: 214
>>> EffectivePolicyImpl.initialisePolicy(EndpointInfo,
>>> BindingOperationInfo, PolicyEngineImpl, boolean) line: 101
>>> EffectivePolicyImpl.initialise(EndpointInfo, BindingOperationInfo,
>>> PolicyEngineImpl, Assertor, boolean) line: 79
>>>
>>> InitializingPolicyEngine
>>> (PolicyEngineImpl).getEffectiveServerResponsePolicy(EndpointInfo,
>>> BindingOperationInfo, Destination) line: 171
>>> ServerPolicyOutInterceptor.handle(Message) line: 77
>>>
>>> ServerPolicyOutInterceptor
>>> (AbstractPolicyInterceptor).handleMessage(Message) line: 56
>>> PhaseInterceptorChain.doIntercept(Message) line: 221
>>> OutgoingChainInterceptor.handleMessage(Message) line: 74
>>> PhaseInterceptorChain.doIntercept(Message) line: 221
>>> ChainInitiationObserver.onMessage(Message) line: 78
>>> JettyHTTPDestination.serviceRequest(ServletContext,
>>> HttpServletRequest, HttpServletResponse) line: 278
>>> JettyHTTPDestination.doService(ServletContext, HttpServletRequest,
>>> HttpServletResponse) line: 252
>>> JettyHTTPHandler.handle(String, HttpServletRequest,
>>> HttpServletResponse, int) line: 70
>>> ContextHandler.handle(String, HttpServletRequest,
>>> HttpServletResponse, int) line: 726
>>> ContextHandlerCollection.handle(String, HttpServletRequest,
>>> HttpServletResponse, int) line: 206
>>> Server(HandlerWrapper).handle(String, HttpServletRequest,
>>> HttpServletResponse, int) line: 152
>>> Server.handle(HttpConnection) line: 324
>>> HttpConnection.handleRequest() line: 505
>>> HttpConnection$RequestHandler.content(Buffer) line: 842
>>> HttpParser.parseNext() line: 730
>>> HttpParser.parseAvailable() line: 205
>>> HttpConnection.handle() line: 380
>>> SslSocketConnector$SslConnection(SocketConnector$Connection).run()
>>> line: 228
>>> SslSocketConnector$SslConnection.run() line: 620
>>> BoundedThreadPool$PoolThread.run() line: 450
>>>
>>> But in this case, there are no interceptors installed in the response
>>> interceptor chain. As a consequence, the request "fails" (in a manner
>>> described below) with a "None of the policy alternatives can be
>>> satisfied" message, which is set in the
>>> PolicyVerificationOutInterceptor.
>>>
>>> Note, however, that the SOAP:Fault is actually embedded in the response:
>>>
>>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/ envelope/">
>>> <soap:Body>
>>> <sayHiResponse xmlns="http://acme.com/greeter/types">
>>> <responseType>Bonjour tony</responseType>
>>> </sayHiResponse>
>>> <soap:Fault>
>>> <faultcode>soap:Server</faultcode>
>>> <faultstring>None of the policy alternatives can be
>>> satisfied.</faultstring>
>>> </soap:Fault>
>>> </soap:Body>
>>> </soap:Envelope>
>>>
>>> Oops. Something seems awry with the phase in which the fault is
>>> written.
>>>
>>> But regardless, should the effective policy on the response be the
>>> same as the effective policy on the request? Or should policy
>>> assertion implementors code their interceptors to handle the response
>>> chain, as well as the request?
>>>
>>> -Fred
>>
>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Server Response Policy
Posted by Fred Dushin <fr...@dushin.net>.
Well I can definitely work around the problem, just by configuring my
interceptors to check off the same assertions on the outbound side.
This requires though, that I stick a reference to some request state
information on the exchange, and that I ensure that an OutInterceptor
is installed before between the policy interceptors on the outbound
side.
My solution seems a little hokey to me -- I'd rather that the
AssertionInfo objects I've already ticked off as asserted be the same
instances on the response channel, but that's not the case (I have not
looked yet to see where a copy of the AssertionInfoMap is made --
maybe that's the real issue here, as opposed to the same effective
policy on the inbound and outbound sides).
-Fred
On Aug 8, 2008, at 11:55 AM, Daniel Kulp wrote:
> Hmm.. I'm not really sure, but this MAY be correct behavior.
>
> I'm thinking something like the MTOM policy. For that, there has
> to be
> something on the outgoing side to see if the MTOM policy is there
> and turn on
> MTOM if so.
>
> It's somewhat like some policies are "enforced" on the incoming chain,
> and "configured" on the outgoing chains. Thus, the policy should
> be able to
> handle both sides of that.
>
> Dan
>
>
>
> On Thursday 07 August 2008 3:25:31 pm Fred Dushin wrote:
>> I'm having trouble with the CXF policy framework, which is causing a
>> little bit of grief. I think this is a developer, as opposed to a
>> user issue, as I /think/ it points to a bug in the policy framework.
>> If not, I can migrate the conversation to the users list.
>>
>> What I'm finding is that a CXF server that has policy defined at the
>> endpoint (I'm using the CXF policy feature, whereby you can reference
>> a WS-Policy expression in Spring) is effectively treating the
>> operative policy in the server on the outbound interceptor chain the
>> same way as it does on the inbound interceptor chain.
>>
>> Let me be more concrete. Assume the following config fragment in
>> Spring:
>>
>> <jaxws:endpoint ... >
>> <jaxws:features>
>> <cxfp:policies>
>> <wsp:PolicyReference URI="#MyPolicy"/>
>> </cxfp:policies>
>> </jaxws:features>
>> </jaxws:endpoint>
>> ...
>> <wsp:Policy wsu:Id="MyPolicy">
>> ...
>> </wsp:Policy>
>>
>> So on the inbound server side, I definitely get this as the effective
>> policy, and I can do policy enforcement by setting the asserted flag
>> on various assertions selected (in the case of inbound server,
>> everything is selected). Note that I have interceptors installed in
>> the runtime to do this enforcement.
>>
>> However, on the outbound response, I'm getting the same effective
>> policy, and I can see how it's getting set -- precisely in the
>> following stacktrace (pardon the wrap):
>>
>> Thread [btpool2-1] (Suspended)
>>
>> InitializingPolicyEngine
>> (PolicyEngineImpl).getEndpointPolicy(EndpointInfo, EndpointPolicy,
>> boolean, Assertor) line: 220
>>
>> InitializingPolicyEngine
>> (PolicyEngineImpl).getServerEndpointPolicy(EndpointInfo, Destination)
>> line: 214
>> EffectivePolicyImpl.initialisePolicy(EndpointInfo,
>> BindingOperationInfo, PolicyEngineImpl, boolean) line: 101
>> EffectivePolicyImpl.initialise(EndpointInfo, BindingOperationInfo,
>> PolicyEngineImpl, Assertor, boolean) line: 79
>>
>> InitializingPolicyEngine
>> (PolicyEngineImpl).getEffectiveServerResponsePolicy(EndpointInfo,
>> BindingOperationInfo, Destination) line: 171
>> ServerPolicyOutInterceptor.handle(Message) line: 77
>>
>> ServerPolicyOutInterceptor
>> (AbstractPolicyInterceptor).handleMessage(Message) line: 56
>> PhaseInterceptorChain.doIntercept(Message) line: 221
>> OutgoingChainInterceptor.handleMessage(Message) line: 74
>> PhaseInterceptorChain.doIntercept(Message) line: 221
>> ChainInitiationObserver.onMessage(Message) line: 78
>> JettyHTTPDestination.serviceRequest(ServletContext,
>> HttpServletRequest, HttpServletResponse) line: 278
>> JettyHTTPDestination.doService(ServletContext, HttpServletRequest,
>> HttpServletResponse) line: 252
>> JettyHTTPHandler.handle(String, HttpServletRequest,
>> HttpServletResponse, int) line: 70
>> ContextHandler.handle(String, HttpServletRequest,
>> HttpServletResponse, int) line: 726
>> ContextHandlerCollection.handle(String, HttpServletRequest,
>> HttpServletResponse, int) line: 206
>> Server(HandlerWrapper).handle(String, HttpServletRequest,
>> HttpServletResponse, int) line: 152
>> Server.handle(HttpConnection) line: 324
>> HttpConnection.handleRequest() line: 505
>> HttpConnection$RequestHandler.content(Buffer) line: 842
>> HttpParser.parseNext() line: 730
>> HttpParser.parseAvailable() line: 205
>> HttpConnection.handle() line: 380
>> SslSocketConnector$SslConnection(SocketConnector$Connection).run()
>> line: 228
>> SslSocketConnector$SslConnection.run() line: 620
>> BoundedThreadPool$PoolThread.run() line: 450
>>
>> But in this case, there are no interceptors installed in the response
>> interceptor chain. As a consequence, the request "fails" (in a
>> manner
>> described below) with a "None of the policy alternatives can be
>> satisfied" message, which is set in the
>> PolicyVerificationOutInterceptor.
>>
>> Note, however, that the SOAP:Fault is actually embedded in the
>> response:
>>
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/
>> envelope/">
>> <soap:Body>
>> <sayHiResponse xmlns="http://acme.com/greeter/types">
>> <responseType>Bonjour tony</responseType>
>> </sayHiResponse>
>> <soap:Fault>
>> <faultcode>soap:Server</faultcode>
>> <faultstring>None of the policy alternatives can be
>> satisfied.</faultstring>
>> </soap:Fault>
>> </soap:Body>
>> </soap:Envelope>
>>
>> Oops. Something seems awry with the phase in which the fault is
>> written.
>>
>> But regardless, should the effective policy on the response be the
>> same as the effective policy on the request? Or should policy
>> assertion implementors code their interceptors to handle the response
>> chain, as well as the request?
>>
>> -Fred
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Server Response Policy
Posted by Daniel Kulp <dk...@apache.org>.
Hmm.. I'm not really sure, but this MAY be correct behavior.
I'm thinking something like the MTOM policy. For that, there has to be
something on the outgoing side to see if the MTOM policy is there and turn on
MTOM if so.
It's somewhat like some policies are "enforced" on the incoming chain,
and "configured" on the outgoing chains. Thus, the policy should be able to
handle both sides of that.
Dan
On Thursday 07 August 2008 3:25:31 pm Fred Dushin wrote:
> I'm having trouble with the CXF policy framework, which is causing a
> little bit of grief. I think this is a developer, as opposed to a
> user issue, as I /think/ it points to a bug in the policy framework.
> If not, I can migrate the conversation to the users list.
>
> What I'm finding is that a CXF server that has policy defined at the
> endpoint (I'm using the CXF policy feature, whereby you can reference
> a WS-Policy expression in Spring) is effectively treating the
> operative policy in the server on the outbound interceptor chain the
> same way as it does on the inbound interceptor chain.
>
> Let me be more concrete. Assume the following config fragment in
> Spring:
>
> <jaxws:endpoint ... >
> <jaxws:features>
> <cxfp:policies>
> <wsp:PolicyReference URI="#MyPolicy"/>
> </cxfp:policies>
> </jaxws:features>
> </jaxws:endpoint>
> ...
> <wsp:Policy wsu:Id="MyPolicy">
> ...
> </wsp:Policy>
>
> So on the inbound server side, I definitely get this as the effective
> policy, and I can do policy enforcement by setting the asserted flag
> on various assertions selected (in the case of inbound server,
> everything is selected). Note that I have interceptors installed in
> the runtime to do this enforcement.
>
> However, on the outbound response, I'm getting the same effective
> policy, and I can see how it's getting set -- precisely in the
> following stacktrace (pardon the wrap):
>
> Thread [btpool2-1] (Suspended)
>
> InitializingPolicyEngine
> (PolicyEngineImpl).getEndpointPolicy(EndpointInfo, EndpointPolicy,
> boolean, Assertor) line: 220
>
> InitializingPolicyEngine
> (PolicyEngineImpl).getServerEndpointPolicy(EndpointInfo, Destination)
> line: 214
> EffectivePolicyImpl.initialisePolicy(EndpointInfo,
> BindingOperationInfo, PolicyEngineImpl, boolean) line: 101
> EffectivePolicyImpl.initialise(EndpointInfo, BindingOperationInfo,
> PolicyEngineImpl, Assertor, boolean) line: 79
>
> InitializingPolicyEngine
> (PolicyEngineImpl).getEffectiveServerResponsePolicy(EndpointInfo,
> BindingOperationInfo, Destination) line: 171
> ServerPolicyOutInterceptor.handle(Message) line: 77
>
> ServerPolicyOutInterceptor
> (AbstractPolicyInterceptor).handleMessage(Message) line: 56
> PhaseInterceptorChain.doIntercept(Message) line: 221
> OutgoingChainInterceptor.handleMessage(Message) line: 74
> PhaseInterceptorChain.doIntercept(Message) line: 221
> ChainInitiationObserver.onMessage(Message) line: 78
> JettyHTTPDestination.serviceRequest(ServletContext,
> HttpServletRequest, HttpServletResponse) line: 278
> JettyHTTPDestination.doService(ServletContext, HttpServletRequest,
> HttpServletResponse) line: 252
> JettyHTTPHandler.handle(String, HttpServletRequest,
> HttpServletResponse, int) line: 70
> ContextHandler.handle(String, HttpServletRequest,
> HttpServletResponse, int) line: 726
> ContextHandlerCollection.handle(String, HttpServletRequest,
> HttpServletResponse, int) line: 206
> Server(HandlerWrapper).handle(String, HttpServletRequest,
> HttpServletResponse, int) line: 152
> Server.handle(HttpConnection) line: 324
> HttpConnection.handleRequest() line: 505
> HttpConnection$RequestHandler.content(Buffer) line: 842
> HttpParser.parseNext() line: 730
> HttpParser.parseAvailable() line: 205
> HttpConnection.handle() line: 380
> SslSocketConnector$SslConnection(SocketConnector$Connection).run()
> line: 228
> SslSocketConnector$SslConnection.run() line: 620
> BoundedThreadPool$PoolThread.run() line: 450
>
> But in this case, there are no interceptors installed in the response
> interceptor chain. As a consequence, the request "fails" (in a manner
> described below) with a "None of the policy alternatives can be
> satisfied" message, which is set in the
> PolicyVerificationOutInterceptor.
>
> Note, however, that the SOAP:Fault is actually embedded in the response:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <sayHiResponse xmlns="http://acme.com/greeter/types">
> <responseType>Bonjour tony</responseType>
> </sayHiResponse>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>None of the policy alternatives can be
> satisfied.</faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
>
> Oops. Something seems awry with the phase in which the fault is
> written.
>
> But regardless, should the effective policy on the response be the
> same as the effective policy on the request? Or should policy
> assertion implementors code their interceptors to handle the response
> chain, as well as the request?
>
> -Fred
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Server Response Policy
Posted by Glen Mazza <gl...@gmail.com>.
Fred Dushin-3 wrote:
>
> But regardless, should the effective policy on the response be the
> same as the effective policy on the request? Or should policy
> assertion implementors code their interceptors to handle the response
> chain, as well as the request?
>
Does WS-SecurityPolicy have to anything to say for this--how to configure
request and response rules differently?
I'm not sure I'm understanding you correctly. If you're saying should the
security (or other WS-*) rules be the same on both the request and
response--I don't think so. I could imagine a service requiring a signature
and/or encryption or username/passwords but the client not requiring it on
the response. Kind of how WSS4J configuration works today.
FWIW, Metro maintains policies both client- and service-side, with differing
information and rules. However, the client does read the service WSDL to
see security requirements for the request (I think the service provider
reads its own WSDL though to see what it needs to do for the response--the
client-side policy really just has username/password or client cert info.)
Glen
--
View this message in context: http://www.nabble.com/Server-Response-Policy-tp18877899p18882270.html
Sent from the cxf-dev mailing list archive at Nabble.com.