On Tue, Jun 14, 2011 at 8:39 AM, Simon Laws <simonsl...@googlemail.com> wrote: > On Tue, Jun 14, 2011 at 8:24 AM, ant elder <ant.el...@gmail.com> wrote: >> On Tue, Apr 19, 2011 at 5:03 PM, Simon Laws <simonsl...@googlemail.com> >> wrote: >> >> <snip> >> >>> I ended up finding that I was pretty comfortable about having a domain >>> on disc and then starting nodes with minimal configuration, I'd like >>> to look at working this up into a real piece of code in the shell or >>> the launcher. Anyone have any thoughts about this. >>> >> >> I've been wondering how to do a similar type of thing but in as simple >> as possible a way and so i'd quite like to avoid having to use a >> node.xml file. An alternative could be to use the file directory names >> to define what the domain/node looks like. To explore that I've added >> a new method createNode(File) to TuscanyRuntime where the File points >> to a file system directory which contains all the contributions and >> configuration. There's a test DirectoryDomainTestCase and a couple of >> test domain folders at: >> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-node/src/test/resources/test-domains. >> This looks like it has some potential to me, and it could be used to >> extend the existing support for contribution folders in places like >> the webapp runtime and Tomcat deep integration. >> >> ...ant >> > > Just for comparison. [1] was what I came up with. I was also using > directory names as a convention for naming the domain and the nodes > running within it. Looking at the test-domain version what do the > composite file and xml file at the top level mean? Also where is the > configuration that tells you what is running where? Is that separate? > > [1] > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/testing/itest/nodes/two-jvm-hazelcast/src/test/resources/ >
Ok, i hadn't noticed that. They're quite similar, AFAICT the main functional differences between the two approaches is that your one enables contributions to be shared between nodes but at the expense of having to explicitly list the contributions for a node in a config file whereas the other approach you don't need any config file but if a contribution needs to be used in more than one node then it needs to be copied. To answer those other questions - You don''t need any configuration file to say whats running where because all the contributions in the directory are just installed in the Node. The Domain Node API supports all of the things from section 10 in the Assembly spec so thats what i wanted to try to get this file system approach to do with as little other config as possible. So you can modify a contributions sca-contribution.xml metadata by having an additional one as a side file and this approach uses a side file with the contribution name but with a .xml file type. And you can add additional deployable composites to a contribution so thats what the .composite files are for with the name starting with the contribution name and ending with .composite and anything in the middle of the name which is ignore but needed just to make the file unique. You can also explicitly define the dependent contributions uri's for a contribution with a property in the domain.properties file. So with that for example you could drop any old non-sca jar into the folder and have it used in a domain, and as required add side files for sca-contribution.xml or .composites that use the jar. I can see advantages and disadvantages with both approaches. I guess we could simply support both so perhaps if there is a file named node.xml in the folder than use that for all the config otherwise do it the way that createNode(File) is currently working. For simple things you can probably get away without needing a node.xml but for more complicated setups then node.xml might make it easier. ...ant
