On Tue, Jun 14, 2011 at 10:31 AM, Simon Laws <[email protected]> wrote: > ... snip >> >> 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. > > Yes, to add a bit of weight to this a scenario I had imagined was a > distributed file system where the ops just set up the domain in one > place by copying files into a folder. They then start nodes on various > machines and, by simply matching the node name with the appropriate > file on disc, the node is able to tell which composites to start. I'm > not so concerned whether the node loads all or just some of the > contributions but wanted to control what was actually running where. > Also I wanted to be able to control the base URLs for the case where I > start a node on a machine where, for example, the default HTTP ports > are being used by some other non-SCA related software. I want to be > specific and don't want our code just to choose a port because I have > to also configure the firewall. > >> >> 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. > > Ok, makes sense. > >> You can also explicitly define >> the dependent contributions uri's for a contribution with a property >> in the domain.properties file. > > What would that property look like?
See https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/domain-node/src/test/resources/test-domains/dependencies/ >> 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. > > +1 although, if we're not going with sub-directories, I would add a > convention something like. > > nameofnode-node.xml > > or similar to cover the shared file system case. > I'm not sure i understand what you mean with that, could you explain again or add a test showing what you mean? ..ant
