I'm glad to see my post about this made it to the ML. I have not
received a copy back yet myself from the server.
I had thought about this approach and I think it may be the best
solution. One possible point against it is that there could be some
bindings that are able to support a suitable callback MEP themselves
in a more efficient way than having completely separate forward and
callback paths. Having these bindings be callback aware and able to
control the callback interactions would be better than having the
core create two independent one-way bindings that don't know about
each other.
There's also the question of how the forward and reverse bindings and
forward calls and callbacks are correlated. At present there is code
in the bindings to perform this correlation, in a binding-specific way.
If we move this code to the core, we will need to be sure that the
approach we come up with is suitable for all binding types and all
possible endpoints.
On the plus side, this approach would make both the core and the
bindings a lot simpler and I am inclined to think that on balance it
will be worth making these changes. I would like to stage this by
first completing the implementation that I currently have, which is
functionally equivalent to what you are suggesting. The new code for
this in the Web Service binding looks more complicated than it is
because the code is currently dual-pathed to support both the current
tactical solution and the new approach. When I remove the dual-pathing
and the massive code duplication, you will see that it is already very
close to what you suggest.
Now let's come back to the problem that I cam currently seeing. I'm not
sure if you have looked into the details of the failure. My code is
effectively already doing exactly what you suggest (including registering
a servlet mapping for the pseudo-service that supports the callback
reference), and I am seeing a "servlet unavailable" message when trying
to invoke the servlet. I'd like to understand why this is happening
before making all the code change you are suggesting, which could possibly
still result in the same error because they will be doing the same thing.
If anyone else understands how servlet registration and servlet mapping
works and could help me today to look into this problem, I would
appreciate it. Otherwise I will continue to educate myself in this
area and try some other scenarios to attempt to narrow it down. The first
thing I will try is doing exactly what Raymond suggests, but manually
in the SCDL, to see whether the problem still occurs.
Simon
Raymond Feng wrote:
Hi, Simon.
I think the problem is that we need to create an internal callback
service to listen on the callbacks from the web service protocol. Please
see my proposal [1].
If we do so, a servlet mapping "MyClientComponent/$callback$.myService"
for this special service will be registered when it is activated.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20497.html
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Saturday, July 21, 2007 5:54 PM
Subject: Problem with new callback implementation for the Web Service
binding
I have come across a problem with my new implementation of callbacks
across the Web Service binding. This code handles callbacks in the same
way as forward calls by creating an Axis service and a servlet on the
reference end to receive the callbacks, and using a normal Axis2
OperationClient on the service end to invoke them.
The problem is an error
org.apache.axis2.AxisFault: Transport error: 404 Error: Servlet
/MyClientComponent/$callback$.myService is not available
when the service side attempts to make a callback to the client side.
This URI is one I have constructed to represent a reference callback
endpoint.
I have created a servlet and registered a mapping for this callback
URI using
the same code that does this successfully for a service. I don't know
why
my callback servlet isn't available but my servlet for the forward
call works OK.
In the following trace there are some debug println calls showing that
the
servlet mapping is being registered with the correct URI, and that the
server
callback invocation back to the client is using the same URI that was
extracted
from WS-Addressing information sent on the forward call.
To run the new code path and see this problem, you need my latest
patch (patch2)
applied, and you also need to make some small modifications to the
code in
binding-ws-axis2 and to the SCDL and WSDL files in simple-callback-ws.
1. In Axis2ReferenceBindingProvider.java and
Axis2ServiceBindingProvider.java,
change the value of "tactical" from true to false, then rebuild the
binding-ws-axis2 module.
2. In simple-callback-ws, change the WSDL to use a one-way MEP rather
than
a two-way MEP for the call to someMethod (see commented
instructions).
Also change the SCDL to specify a wsdl.port instead of a
wsdl.binding for
the callback (see commented instructions). Rebuild
simple-callback-ws and
you should see the following trace.
Any suggestions for what is causing this problem would be very
gratefully received!
Simon
Running simplecallback.SimpleCallbackTestCase
log4j:WARN No appenders could be found for logger
(org.apache.axiom.om.util.StAXUtils).
log4j:WARN Please initialize the log4j system properly.
Axis2ServiceProvider: adding servlet mapping for
http://localhost:8085/MyClientComponent/$callback$.myService
(cut)
... 47 more
RuntimeException invoking receiveResult:
java.lang.reflect.UndeclaredThrowableException
22-Jul-2007 00:31:28 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8085
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.265
sec <<< FAILURE!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
