Did you receive my previous mail?
I did not receive any answer nor the mail was accessible on the web.
Sorry if I'm continuing to submit the problem, but I have no idea if
there are alternatives to this behavior.
Thanks again
Leonardo Campanale ha scritto:
Hello everyone.
I found that if I intentionally throw an AxisFault in my handler. after
the processing of addressing headers, the calls chain really stops and
the pivot is not called at all.
But the AxisServlet obviously considers the event as a fault and
returns a page error (code 500 SC_INTERNAL_SERVER_ERROR) to the
calling client. In this response page I'm able to substitute the
error message with the desired message, coming from the called
service, but I'm not able to change the http headers (unless I rewrite
part of AxisServlet dopost).
So my real concern is about the way to intercept the path toward the
server, and avoid the call to the real pivot, or, in other terms, to
substitute the real pivot with my handler (that manages the addressing
headers)
Thanks again
Leonardo Campanale.
Davanum Srinivas ha scritto:
Ian,
there are several tests in axis test harness for testing these
scenarios and several test cases in jaxrpc tck as well. so we should
be all set...IF you see a problem scenario, can you please refine the
axis tests? (test\wsdl\jaxrpchandler**) and open a bug report? I feel
all the cases are covered though i don't remember exactly the
implementation detail off the top of my head.
-- dims
On Mon, 14 Mar 2005 18:44:26 -0500, Ian Springer <[EMAIL PROTECTED]> wrote:
Davanum Srinivas wrote:
see HandlerChainImpl
-- dims
Dims,
I did see that class. However, looking at JAXRPCHandler, it basically
always creates a HandlerChainImpl that contains only a single handler,
the one specified via the className option in the wsdd. Also,
JAXRPCHandler#invoke() ignores the return values of handleRequest() and
handleResponse(), and JAXRPCHandler#onFault() ignores the return value
of handleFault(). So it looks to me like if one of my JAX-RPC Handler's
handle*() methods returns false, HandlerChainImpl will also return
false, but JAXRPCHandler never propogates this to the rest of the Axis
handler chain. So the request will still get passed through any other
Axis handlers, including other JAX-RPC handlers, that are configured in
the wsdd. Or am I missing something?
Ian
--- Ian Springer <[EMAIL PROTECTED]> wrote:
Leonardo Campanale wrote:
Finally I was able to write a class (handler) able to intercept the
call and reroute the message to a final destination.
To do this I wrote the handleRequest where I had to call the service
through the To field of the ws-a headers and I had to save the
response in some way (in a map)
On the return path toward the client I had to intercept the response
message (handleResponse) and I substituted the message with the saved
value.
What happens now is that in my handleRequest I forward the message to
the desided address, but the call continues also to be sent to the
TargetEndpointAddress specified in the client call. As a consequence
of this behavior sometimes this second call fails (for example bacause
of different signatures between the desired service and the endpoint
service ). To face this scenario I had to override also the
handleFault method in my handler.
So the problem is now that, on the handleRequest, it would be better
to stop the message path on the server and use this handler as a
pivot, in order to avoid that the original service is called.
How is it possible?
JAX-RPC says that handleRequest() can return false to short-circuit
further processing of the handler chain, as well as prevent dispatching
to the target endpoint - see section 12.2.2 of the JAX-RPC 1.1 spec.
Unfortunately, looking at org.apache.axis.handlers.JAXRPCHandler, it
doesn't look to me as if Axis complies with this part of the spec.
Ian
Davanum Srinivas - http://webservices.apache.org/~dims/
|
