On Wed, Dec 31, 2008 at 1:09 PM, ant elder <[email protected]> wrote:
> > > On Wed, Dec 10, 2008 at 11:08 PM, Simon Laws <[email protected]>wrote: > >> I'm just reviewing my understanding of the relationship between >> contributions and composites with a view to reviewing how users start the >> Tuscany Java SCA runtime and configure SCA application, It doesn't look like >> what the OASIS specs say on this subject differs much from the OSOA specs. >> >> Tuscany users see two primary modes of operation of the Java SCA runtime; >> >> Standalone - the SCA application runs on a single Tuscany SCA node >> Distributed - the SCA application is distributed across a number >> distributed nodes which are all running as part of the same domain >> >> As we aim to make the life of the SOA developer easier I imagine that >> people are interested in the distributed configuration however the >> standalone configuration is useful, particularly for us when testing. >> >> The composites which describe the various composite assemblies that >> combine to form the SCA application are added to the runtime contained >> within one or more contributions (the contribution is just a handy >> packaging notion). There are a number of ways contributions and composites >> can >> be organized. >> >> An SCA application can be made up of >> >> i/ A single contribution >> ii/ Multiple contributions. In this case some contributions may depend on >> one other. >> >> Each contribution can contain >> >> a/ one or more composite files with none listed in >> META-INF/sca-contribution.xml >> b/ a composite file and META-INF/sca-contribution.xml which defines one >> deployable composite >> c/ many composite files and META-INF/sca-contribution.xml which defines >> more than one deployable composite >> d/ no composite file >> > > Is there a reason for the distinction between b/ and c/? Couldn't b/ just > be considered a specific configuration of c/? > > Also note that the assembly spec does say that a contribution should > contain an sca-contribution.xml file > > > >> >> Alternatively >> >> e/ a composite can be provided independently of a contribution as just a >> string or external file >> > > Is e/ actually mentioned in the SCA specs anywhere (I can't find it)? > > >> >> In 1.x the user starts the runtime from the command line in the following >> ways. >> >> Standalone >> Run a node/webapp and tell it what contribution/composite to run, e.g. >> >> java -jar nodeLauncher.jar compositeURI contributionLocation >> > > Does "java -jar nodeLauncher.jar" actually work in 1.x? I think virtually > all the samples don't do that but instead use one of: > - command line Java using binary distribution tuscany-sca-manifest.jar > - Ant build script using the tuscany-sca-manifest.jar > - Ant build script using the tuscany-maven-ant-generator plugin > > > >> >> So this can exploit i/ a/ and b/ (but in this case I don't think >> sca-contribution.xml takes any part) >> > > AFAIK the sca-contribution.xml _is_ used in 1.x, and additionally also the > special sca-deployables folder. For example, in the SCANodeFactory > createNode methods you can use null for the composite uri if the > contribution defines either a deployable composite in the > sca-contribution.xml file or has a .composite file in the sca-deployables > folder. (and as the spec says a contribution should contain an > sca-contributions.xml file this should usually work) > > >> >> Distributed >> Run a domain and configure it >> >> java -jar nodeLauncher.jar domain >> >> Using the domain management GUI; >> Specify node configurations >> Add contributions >> Associate composites with nodes >> >> Start a node given a URL to it's configuration >> >> java -jar nodeLauncher.jar http://localhost:8080/mydomain/mynode >> >> Node runs a single composite (from one or more associated contributions) >> >> >> So this, as a whole, can exploit i/ ii/ a/ b/ c/ d/ (but again I'm not >> sure that sca-contribution.xml is consulted) >> >> Does this sounds right so far? >> >> Simon >> > > How to start a Tuscany runtime is interesting, i think we should understand > what it is we're really want to achieve and then work out what the best > approach is. > > The "java -jar nodeLauncher" approach is an alternative to > tuscany-sca-manifest.jar or the Ant scripts for starting Tuscany at a > command prompt and enables the launcher class to programatically configure > the classpath environment instead of configuring the environment in the Ant > build.xml or the manifest jar classpath entry. > > What are the reasons and benefits for changing to use a launcher program? > One drawback of the launcher approach is that it makes it hard to see what > the environment is being used, for example, the current launcher class does > all sorts of messing about with jar filtering based on jar file names and > folders, whereas using an Ant build.xml makes it quite clear and most people > are familiar with using Ant. If some osrt of programatic launcher really is > needed then another approach could be to use a batch or shell script which > is what most projects that start some sort of runtime do (tomcat, geronimo, > synapse, etc), and the script approach has the benefit of being plain text > so its still easy to see what environment gets configured. > > ...ant > > Bring this thread up again as it went quiet over the year end break, anyone have any more comments?
