Simon Laws wrote:
On Nov 22, 2007 9:19 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
The Continuum build is failing because the unit test for the new
sample callback-ws-client that I recently added to the build is
selecting port 8080 for the callback, and this port is already in
use on the build server.
The Web Service binding used to use a hard-wired value of port
8085 by default, if no explicit port was specified in the binding
or the WSDL. This allowed samples and itests that use callbacks
over Web services to run on the Continuum server, because port
8085 was not in use. The code in the Web Service binding was
changed within the last few weeks to remove the hard-coded value
and now seems to be allocating port 8080 by default. How is this
allocation determined, and how can I force some other port to
be chosen?
For now I have removed the callback-ws-client sample from the
build until this issue is resolved.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Simon,
Moving to the new node interfaces should make this work. There is some code
to take the port number from
The WSDL or binding url if its provided
Form a default deduced by looking at other binding URLs in the composite if
any are provided
From the node URL if provided
By detecting a free port if none of the above work.
I use the node interface in a couple of places now, e.g. the conversation-ws
itest [1]. See setUp(). Note that here I'm providing neither a node URI or a
domain URI so you see two nulls on the createSCANode() method. This means
that the node will not try and connect to a wider domain and that the node
will find a free port to work on automatically assuming absolute endpoints
are not specified in the composite file.
Note. just looking back that the composite file in this test I've done
something a little strange with the binding urls in giving them a WSDL
binding reference. Not sure why I left it like this. I need to go and
remove them so ignore then.
Regards
Simon
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/conversations-ws/src/test/java/org/apache/tuscany/sca/itest/conversational/ConversationWSDLTestCase.java
Thanks for the pointer. I have converted the callback-ws-client and
callback-ws-service samples to use the new Node API. The code I used
was slightly different from that in conversations-ws because the
callback-ws-client sample's unit test needs to load a contribution
from the callback-ws-server module.
Having got the code working, I found that 6 lines of code are now
needed to replace the one line that was required using the previous
call to code in host-embedded. This makes the tests harder to read
as well as harder to write. I therefore added a utility method in
SCANodeFactory to handle the simplest possible scenario of creating
a single node with an embedded domain, finding a specified composite
on the classpath and loading the contribution that contains this
composite, deploying this composite on the node, and starting the
node. This createNodeWithComposite() method allows the previous
one-line test case setup of:
SCADomain scaDomain = SCADomain.newInstance("callbackws.composite");
to remain as a one-line setup, now:
SCANode node = SCANodeFactory.createNodeWithComposite("callbackws.composite");
I also added a getInstance() method to SCANodeFactory for use by
createNodeWithComposite() as well as for use by user code. This
returns a singleton SCANodeFactory instanc, unlike the current
newInstance() method which always creates a new instance.
With these changes, the callback service is no longer exposed
on port 8080. This should allow these samples to build OK on
the Continuum build machine.
I checked in these changes under r597750.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
