-
15. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
adinn Jul 19, 2010 6:31 AM (in response to jim.ma)Hi Jim,
Jim Ma wrote:
When I use a ssl client running in another jvm to send oneway request, the server can always get the "https" schema without error. Can you see if there any difference between my test setup with XTS test code and configuration here?
Sorry for the delay in replying -- I have been very busy on other stuff. I'll see if I can isolate what happens in my case that makes it different from yours. If I cannot work out what is happening then I will provide instructions for running the specific XTS test(s) which manifests the problem.
regards,
Andrew Dinn
-
16. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
adinn Jul 22, 2010 10:36 AM (in response to adinn)Hi Jim,
I am not sure what is different in my code that makes request.getScheme() fail with an NPE while your code works ok but I think it is just luck.
I traced execution through a test case and it appears that the incoming message relates to a valid request. Because this is a one way message there is a handover of control in ContextUtils at line 416
416 inMessage.getInterceptorChain().pause();
getExecutor(inMessage).execute(new Runnable() {
public void run() {
421 inMessage.getInterceptorChain().resume();
}I checked the request by stopping at 416 and looking up the stack to find the request. The HttpServletRequest object is actually a facade object which indirects to an underlying catalina connector request. It had a name like "Current Servlet stack for thread http-127.0.0.1-8080-1 [S] ActivationService [org.jboss.wsf.stack.cxf.CXFServletExt]". request.getScheme() worked on this object without a NPE.
I picked control up again in the debugger at 421 but, of course, there was no servlet method up the stack where I coudl locate the request. So, I proceeded to step through the code until the ServiceInvokerInterceptor was called. In AbstractInvoker.invoke() the web service context is set up
public Object invoke(Exchange exchange, Object o)
{
// set up the webservice request context
WrappedMessageContext ctx = new WrappedMessageContext(exchange.getInMessage(), Scope.APPLICATION);
Map<String, Object> handlerScopedStuff = removeHandlerProperties(ctx);
WebServiceContextImpl.setMessageContext(ctx);
101 Object retObj = null;At line 101 I evaluated ctx.get("HTTP.REQUEST") and got another facade hiding a catalina connector request with name "Current Servlet stack for thread default-workqueue-2". However all the fields of this catalina connector request appear to be uninitialised and getScheme() returns null. So, this looks to me like the request is coming out of a thread local and it is pot luck whether the object behind the facade has been initialised or not. IN your tests it may be that a previous call has set values in this object.
regards,
Andrew Dinn
-
17. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
jim.ma Jul 27, 2010 2:30 AM (in response to adinn)Hi Andrew,
Sorry for the late response . I was occupied with the TCK stuff last week.
Thanks for your good analysis. After I added the @Addressing annotation in the service implementation class , I successfully reproduced this error . When I enabled WSA for this oneway operation , I got null value from http request too. This is another bug in CXF when run with Tomcat/JBossWeb.
416 inMessage.getInterceptorChain().pause();
// ... and resume on executor thread
getExecutor(inMessage).execute(new Runnable() {
public void run() {
421 inMessage.getInterceptorChain().resume();
}I debuged the 416 thread for the oneway and WSA enable operation. When this line executed, this thread(http-127.0.0.1-8080-1) will continue to do the left thing to set the http status code and cleanup some thing. The cleanup thing includes the Request.recycle() :
package org.apache.coyote;
public final class Request{
public void recycle() {
bytesRead=0;
contentLength = -1;
contentTypeMB = null;
charEncoding = null;
headers.recycle();
serverNameMB.recycle();
serverPort=-1;
localPort = -1;
remotePort = -1;
available = 0;
cookies.recycle();
parameters.recycle();
unparsedURIMB.recycle();
uriMB.recycle();
decodedUriMB.recycle();
queryMB.recycle();
methodMB.recycle();
protoMB.recycle();
schemeMB.recycle();
instanceId.recycle();
remoteUser.recycle();
authType.recycle();
attributes.clear();
}
}After this executed, all the request information will be cleared. So the interceptors running
in 421 line thread gets the null value from Request.schemeMB.
I created a JIRA in CXF https://issues.apache.org/jira/browse/CXF-2911 and looking at a fix.
Thanks,
Jim
-
18. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
jim.ma Jul 29, 2010 2:35 AM (in response to jim.ma)Hi Andrew, I have fixed this issue in CXF code base . I will merge this fix to the branch for the next release later . It will be picked up in the next jbossws-cxf release.
-
19. Re: Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
adinn Jul 29, 2010 11:47 AM (in response to jim.ma)Jim Ma wrote:
Hi Andrew, I have fixed this issue in CXF code base . I will merge this fix to the branch for the next release later . It will be picked up in the next jbossws-cxf release.
Thanks Jim. Nice work :-)