Re: 2.1.2 on Monday?
On Friday 08 August 2008 7:01:27 pm Glen Mazza wrote: > dkulp wrote: > > The end of next week will be 8 weeks since 2.1.1 was released and we've > > fixed > > a BUNCH of things (something like 58 jira's so far) that would be good > > to get into peoples hands. > > > > Are there any objections to that? If not, I'll get it built monday > > afternoon > > and call the votes. > > Not crucial, but it would be nice to see the problem with the 2 bouncy jars > to be fixed--that was a regression from 2.1.1 over 2.1: > http://issues.apache.org/jira/browse/CXF-1726 > > BTW, what is the Maven command (is there one?) to determine which > dependency brought in another dependency? I think we need an exclusion > filter on whatever is bringing in that jdk 1.3 Bouncy Castle jar. Most likely you are referring to: mvn dependence:tree That should show a nice tree. -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: 2.1.2 on Monday?
dkulp wrote: > > The end of next week will be 8 weeks since 2.1.1 was released and we've > fixed > a BUNCH of things (something like 58 jira's so far) that would be good to > get into peoples hands. > > Are there any objections to that? If not, I'll get it built monday > afternoon > and call the votes. > Not crucial, but it would be nice to see the problem with the 2 bouncy jars to be fixed--that was a regression from 2.1.1 over 2.1: http://issues.apache.org/jira/browse/CXF-1726 BTW, what is the Maven command (is there one?) to determine which dependency brought in another dependency? I think we need an exclusion filter on whatever is bringing in that jdk 1.3 Bouncy Castle jar. Glen -- View this message in context: http://www.nabble.com/2.1.2-on-Monday--tp18894177p18900302.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Server Response Policy
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: ... ... 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
Re: Server Response Policy
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: > > > > > > > > > ... > > ... > > > 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: > > http://schemas.xmlsoap.org/soap/envelope/";> > > http://acme.com/greeter/types";> > Bonjour tony > > > soap:Server > None of the policy alternatives can be > satisfied. > > > > > 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 [EMAIL PROTECTED] http://www.dankulp.c
2.1.2 on Monday?
The end of next week will be 8 weeks since 2.1.1 was released and we've fixed a BUNCH of things (something like 58 jira's so far) that would be good to get into peoples hands. Are there any objections to that? If not, I'll get it built monday afternoon and call the votes. -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
