On Nov 16, 2007 10:58 AM, ant elder <[EMAIL PROTECTED]> wrote: > On Nov 13, 2007 4:25 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > On Nov 13, 2007 4:06 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > Trying to run a domain manager node within a webapp and it fails as > > right > > > now you can only use a domain manager url without a path, eg > > > http://localhost:8080 not http://localhost:8080/tuscany/domainManager. > > I'd > > > like to try to fix this so a path if supported if no one has any > > > objections, > > > also if there are any pointers to where in the node and domain code > this > > > > > is > > > handled that would be great too! > > > > > > ...ant > > > > > No objections from me. It's dealt with in three places.. > > > > SCADomainImpl.init() - sets up the domain runtime > > SCANodeImpl.init() - sets up the node runtime > > SCADomainProxy.start() - sets up a local runtime if no node is provided > > > > The code you are looking for is something like... > > > > // Configure the default server port > > int port = URI.create(domainModel.getDomainURI()).getPort(); > > if (port != -1) { > > ServletHostExtensionPoint servletHosts = > > domainManagementRuntime.getExtensionPointRegistry ().getExtensionPoint( > > ServletHostExtensionPoint.class); > > for (ServletHost servletHost: > servletHosts.getServletHosts > > ()) > > { > > servletHost.setDefaultPort(port); > > } > > } > > > > This is stripping the port out of the provided URL and putting it into > the > > servlet host. I think we would need to change this interface to allow > the > > whole base URL to be set on the servlet host. > > > > External web app container - The web app container controls the actual > > endpoint and the NodeURL simply tells the tuscany runtime what endpoints > > to > > register. It's seems awkward that we have to provide the URL here but > > there > > doesn't appear to be an easy way round it. > > Embedded web app container - The NodeURL should instruct the embedded > > container what base URL to use for services. > > > > For the Node URL you must either provide a valid URL or nothing. If > > nothing > > then one will be chosen for you. > > For Domain URL (at the node) you must either provide the URL of the > domain > > or nothing.If nothing then the node will run standalone. > > > > Regards > > > > Simon > > > > This is working now for the standalone strawman testcase with both the > domain and node running at a url including a path. There's a problem > though > with running it within the same webapp or same Tomcat container (and > probably the Tuscany Geronimo integration) in that the nodes try to talk > to > the domain when they're started but the domain doesn't accept connections > until after the container is completely up and started, so the node sends > the register request to the domain and hangs waiting for the domain to > answer. Not sure whats the best way to get around this, anyone have any > good > ideas? > > ...ant > In trying to understand the problem here I see two scenarios.
- I want to run my webapp as a standalone SCA application in which case I don't specify a domain URL and the node doesn't try to connect to the domain. - I want to run my webapp as part of an SCA domain. The SCADomain could include many nodes using different runtimes in different hosting environments so I think we should expect that it is already available when the webapp is started. I accept that it's possible to start the domain manager within the same webapp but I'm not sure why you would want to. I'm a little more convinced by wanting to start the domain manager in the same Tomcat container. Currently the domain and node SCA applications assume remote connections between each other, hence the problem you are seeing. There are some solutions of increasing complexity... - Advise users not to do it. It's very easy to start the domain using the inbuilt HTTP server. In reality you are likely to want to deploy it as a Web App to some clustered app server so you need to be careful how this is done w.r.t the nodes that are started. - Change the binding used to wire nodes to the domain to be something other than binding.ws that relies on HTTP - Enhance the way that nodes register such that they try again when other API operations are called if they were unsuccessful the first time. Would fail altogether if it can't connect when you start() the node. - Change the domain model to be decentralized so that nodes only contact other nodes. This may still show the problem when more than one node is in the same container. Regards Simon
