On Tue, Jun 14, 2011 at 8:24 AM, ant elder <[email protected]> wrote: > On Tue, Apr 19, 2011 at 5:03 PM, Simon Laws <[email protected]> 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 >
The other part of that which i'd like to get working is to be able to update those contribution and config files while Tuscany is running and have the changes automatically picked up without having to stop and restart Tuscany. At one point we did have some support for that in the Tomcat deep integration and it would be good to get that going again. There are two hard parts to doing that. One is how to work around the locks Java holds on jars when it uses them in a URLClassLoader, and the other is working out what the smallest thing to restart is to pick up whatever has changed. For the locking issue i think there's two things to try - either copy the contribution to a temporary file and have that as whats actually installed while still monitoring the original file for changes and when the happens throw away the old copy and make a new copy. Alternatively unzip (explode) the contribution jar/zip into a new folder and have that folder as whats installed which is similar to how containers like Tomcat work for webapp .war files. For working out the smallest thing to restart i think the minimum may be individual started composites. If there's a started composite from an external .composite file or from a contribution thats exploded on the file system then we can spot if the .composite file gets changed and just restart the individual started composite. Even thats not going to be totally perfect as it would missing restarts of things using composites with <include> or <implementation.composite>. (maybe it would be possible to fnd those by chasing all the pointers in Tuscany, not sure, does any know if we maintain enough links to find that?). Otherwise if anything else changes in a contribution i think we'll just have to reinstall the whole thing and stop/start everything that was using the contribution, i don't think it would be easy or possible to work out what things might be using individual resources like wsdl, xsd, or classes within a contribution. Anyway, thats the type of thing I'm looking at if anyone has any comments or thoughts. ...ant
