Re: Javascript test failure....
I got swamped. I'll get there eventually. On Wed, Aug 6, 2008 at 12:45 PM, Benson Margulies [EMAIL PROTECTED]wrote: The recent change of possible relevance is to make asynchronous operations against the simulated browser be really asynchronous. This particular test is the one I labored over for the woman who ran into the multiple request issue, so sadly it's unlikely to be suffering from some trivial problem. I'll dig into it this evening. There's lots of logging to turn on... On Tue, Aug 5, 2008 at 8:37 PM, Daniel Kulp [EMAIL PROTECTED] wrote: Benson, I'm back on Linux again and I'm now seeing a somewhat random test failure in the javascript module. (50% failure when run top level, less so from within the module) I'm not sure what to make of it or what could be causing it. It also doesn't seem to occur in eclipse so I'm not even sure how I'd debug it. :-( Any ideas? Stack trace: Running org.apache.cxf.javascript.GreeterClientTest Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.547 sec FAILURE! testRequestClosure(org.apache.cxf.javascript.GreeterClientTest) Time elapsed: 0.2 sec ERROR! org.mozilla.javascript.EcmaError: TypeError: Cannot call method getResponseType of null (testcase#1) at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3350) at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3340) at org.mozilla.javascript.ScriptRuntime.typeError(ScriptRuntime.java:3356) at org.mozilla.javascript.ScriptRuntime.typeError2 (ScriptRuntime.java:3375) at org.mozilla.javascript.ScriptRuntime.undefCallError(ScriptRuntime.java:3394) at org.mozilla.javascript.ScriptRuntime.getPropFunctionAndThis(ScriptRuntime.java:2026) at org.mozilla.javascript.optimizer.OptRuntime.callProp0 (OptRuntime.java:117) at org.mozilla.javascript.gen.c227._c0(testcase:1) at org.mozilla.javascript.gen.c227.call(testcase) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) at org.mozilla.javascript.gen.c227.call(testcase) at org.mozilla.javascript.gen.c227.exec(testcase) at org.mozilla.javascript.Context.evaluateString(Context.java:1196) at org.apache.cxf.javascript.JavascriptTestUtilities$2.run(JavascriptTestUtilities.java:226) at org.apache.cxf.javascript.JavascriptTestUtilities.runInsideContext(JavascriptTestUtilities.java:199) at org.apache.cxf.javascript.JavascriptTestUtilities.rhinoEvaluate(JavascriptTestUtilities.java:224) at org.apache.cxf.javascript.JavascriptTestUtilities.rhinoEvaluateConvert(JavascriptTestUtilities.java:287) at org.apache.cxf.javascript.GreeterClientTest.sayHiClosureCaller(GreeterClientTest.java:96) at org.apache.cxf.javascript.GreeterClientTest.access$100 (GreeterClientTest.java:35) at org.apache.cxf.javascript.GreeterClientTest$2.run(GreeterClientTest.java:109) at org.apache.cxf.javascript.GreeterClientTest$2.run(GreeterClientTest.java:108) at org.apache.cxf.javascript.JavascriptTestUtilities.runInsideContext(JavascriptTestUtilities.java:199) at org.apache.cxf.javascript.GreeterClientTest.testRequestClosure(GreeterClientTest.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at
Re: Javascript test failure....
On Thursday 07 August 2008 7:34:49 am Benson Margulies wrote: I got swamped. I'll get there eventually. No problem. I through a System.gc() in there and the problem became much less apparent so it isn't bothing me as much. :-) Maybe 10% from top level. It's probably not really related to the gc(), but more due to an extra wait for ports to close or something. Don't really know. Dan On Wed, Aug 6, 2008 at 12:45 PM, Benson Margulies [EMAIL PROTECTED]wrote: The recent change of possible relevance is to make asynchronous operations against the simulated browser be really asynchronous. This particular test is the one I labored over for the woman who ran into the multiple request issue, so sadly it's unlikely to be suffering from some trivial problem. I'll dig into it this evening. There's lots of logging to turn on... On Tue, Aug 5, 2008 at 8:37 PM, Daniel Kulp [EMAIL PROTECTED] wrote: Benson, I'm back on Linux again and I'm now seeing a somewhat random test failure in the javascript module. (50% failure when run top level, less so from within the module) I'm not sure what to make of it or what could be causing it. It also doesn't seem to occur in eclipse so I'm not even sure how I'd debug it. :-( Any ideas? Stack trace: Running org.apache.cxf.javascript.GreeterClientTest Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.547 sec FAILURE! testRequestClosure(org.apache.cxf.javascript.GreeterClientTest) Time elapsed: 0.2 sec ERROR! org.mozilla.javascript.EcmaError: TypeError: Cannot call method getResponseType of null (testcase#1) at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3 350) at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3 340) at org.mozilla.javascript.ScriptRuntime.typeError(ScriptRuntime.java:3356) at org.mozilla.javascript.ScriptRuntime.typeError2 (ScriptRuntime.java:3375) at org.mozilla.javascript.ScriptRuntime.undefCallError(ScriptRuntime.java:3 394) at org.mozilla.javascript.ScriptRuntime.getPropFunctionAndThis(ScriptRuntim e.java:2026) at org.mozilla.javascript.optimizer.OptRuntime.callProp0 (OptRuntime.java:117) at org.mozilla.javascript.gen.c227._c0(testcase:1) at org.mozilla.javascript.gen.c227.call(testcase) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) at org.mozilla.javascript.gen.c227.call(testcase) at org.mozilla.javascript.gen.c227.exec(testcase) at org.mozilla.javascript.Context.evaluateString(Context.java:1196) at org.apache.cxf.javascript.JavascriptTestUtilities$2.run(JavascriptTestUt ilities.java:226) at org.apache.cxf.javascript.JavascriptTestUtilities.runInsideContext(Javas criptTestUtilities.java:199) at org.apache.cxf.javascript.JavascriptTestUtilities.rhinoEvaluate(Javascri ptTestUtilities.java:224) at org.apache.cxf.javascript.JavascriptTestUtilities.rhinoEvaluateConvert(J avascriptTestUtilities.java:287) at org.apache.cxf.javascript.GreeterClientTest.sayHiClosureCaller(GreeterCl ientTest.java:96) at org.apache.cxf.javascript.GreeterClientTest.access$100 (GreeterClientTest.java:35) at org.apache.cxf.javascript.GreeterClientTest$2.run(GreeterClientTest.java :109) at org.apache.cxf.javascript.GreeterClientTest$2.run(GreeterClientTest.java :108) at org.apache.cxf.javascript.JavascriptTestUtilities.runInsideContext(Javas criptTestUtilities.java:199) at org.apache.cxf.javascript.GreeterClientTest.testRequestClosure(GreeterCl ientTest.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java: 98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(Met hodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4Clas sRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunne r.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.jav a:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:2 7) at
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; responseTypeBonjour tony/responseType /sayHiResponse soap:Fault faultcodesoap:Server/faultcode faultstringNone 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
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.
