Re: [2.x] [DISCUSS] Tuscany runtime launching
On Mon, Jan 19, 2009 at 3:32 PM, Simon Laws simonsl...@googlemail.comwrote: On Sat, Jan 17, 2009 at 10:01 AM, ant elder ant.el...@gmail.com wrote: Seperating this one out to its own email as its a bit long... On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws simonsl...@googlemail.comwrote: Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. I agree with these launcher comments, but using a launcher does have some benefits so here's a proposal for if we do end up using one: Separate out the launcher functionality to its own module which focuses purely on setting up a classpath and calling some main class, with no code to do anything like calling Tuscany specific Node APIs etc, and have that launcher configured by external config files which define the classpath and main class to call. Then provide several config files for the various environments and runtimes we want to support. The launcher jar and config files would go in separate bin folder in the distribution (or maybe the top level folder), and like the old tuscanymanifest jar the launcher jar name wouldn't include a version number to make it simple and consistent across releases. So a distribution would look something like: tuscany-2.0/ bin/launcher.jar bin/default.config bin/osgi.config bin/manager.config bin/myCustomConfigThatUsesJMSandJDK6.config lib/... samples/... To run something like the calculator sample with the standalone runtimeyou'd do: java -jar bin/launcher.jar sample.calculator.jar which would use the default.config and to use one of the other config files you'd set a property or use an additional parameter,eg: java -jar bin/launcher.jar osgi sample.calculator.jar. The config files could be simple Java properties files defining the jars and folders to add to the classpath and the class with the main method to run, and support some simple wildcards, eg: mainClass=org.apache.tuscany.sca.node.NodeMain classpath1=../lib/core/* classpath2=../lib/jetty/* classpath3=../lib/webservices/* Could even be a bit more fancy and support some simple conditionals in the classpath properties to enable only setting a classpath for specific JDKlevels etc. The advantages of this approach is that its parameterized and its no longer mysterious what the launcher is doing. It also makes things very flexible and easy to customize the runtime environment without changing any code, and it goes along with the modularity story by not munging the launcher and tuscany node startup code into one module. What we're trying to do is common for many other projects, I've looked at a whole bunch to see what they do, there are several common approaches from using bat scripts, proprietary launchers to 3rd party launcher projects etc, this particular approach seems best to me, its based on the approach used by Jetty: http://docs.codehaus .org/display/JETTY/A+look+at+the+start.jar+mechanism ...ant Eclipse also does something similar behind eclipse.exe. Sounds like it's worth investigating to me. It satisfies my desire to have a place where you can just go and run contribution while easily making some decisions about the environment you're going to run in and what options to set. Need to keep it simple though as there's a danger of getting carried away with this kind of thing. Simon Ok no objections after a week so I've raised JIRA TUSCANY-2789 to track getting this done. ...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Mon, Jan 19, 2009 at 9:59 AM, Simon Laws simonsl...@googlemail.comwrote: One thing from earlier in the conversation was that it was established there could be multiple deployable composites within a contribution and that there may be multiple contributions, the runtime launching needs to be able to handle that. This impacts things like the command line startup, the Node APIs, and also things like the eclipse plugin which along with right clicking on a single .composite should be able to handle right clicking on a contribution project or multiple selected contribution projects and starting a runtime using all the deployable composites. Yes, we haven't moved that forward any. It's part of the domain scenario discussion. I've created two JIRAs to track this, TUSCANY-2792 to track the API changes, and TUSCANY-2793 to track the enhancements to the eclipse plugin. The launcher aspects can be done as part of the launcher jira, TUSCANY-2789, that already exisits. ...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Sat, Jan 17, 2009 at 9:18 AM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws simonsl...@googlemail.comwrote: On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng enjoyj...@gmail.comwrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond *From:* Simon Laws simonsl...@googlemail.com *Sent:* Tuesday, January 13, 2009 7:20 AM *To:* dev@tuscany.apache.org *Subject:* Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon *User Type 1:* Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: - Contribution Zip/Jar/Directory - Use container specific mechanisms for loading contribution - Webapp (SCA) - construct a WAR and contribute to SCA enable container - Enterprise (SCA) - construct an EAR and contribute to SCA enabled container *User Type 2: * Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: - Tooling - Eclipse plugin, right click on composite file in contribution project. Relies on [*Eclipse Plugin*] - Command line (includes running from Ant) - see * below, this relies on a *[TuscanyLauncher]* - Webapp (Generic) - construct a WAR with appropriately configured web.xml using * [TuscanyServletFilter]* or *[ TuscanyContextListener]* as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. *User Type 3 * Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: - Tooling - dependency on Tuscany library from *[Eclipse Plugin]* - dependency on Tuscany modules from distribution. Set up manually - dependency on Tuscany modules from local maven repo (mvn -Peclipse) - Command line(includes running from Ant) - java MyClass.jar - Specify the required jars on the classpath either manually or with *[tuscany-sca
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Mon, Jan 19, 2009 at 9:59 AM, Simon Laws simonsl...@googlemail.comwrote: On Sat, Jan 17, 2009 at 9:18 AM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws simonsl...@googlemail.comwrote: On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng enjoyj...@gmail.comwrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond *From:* Simon Laws simonsl...@googlemail.com *Sent:* Tuesday, January 13, 2009 7:20 AM *To:* dev@tuscany.apache.org *Subject:* Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon *User Type 1:* Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: - Contribution Zip/Jar/Directory - Use container specific mechanisms for loading contribution - Webapp (SCA) - construct a WAR and contribute to SCA enable container - Enterprise (SCA) - construct an EAR and contribute to SCA enabled container *User Type 2: * Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: - Tooling - Eclipse plugin, right click on composite file in contribution project. Relies on [*Eclipse Plugin*] - Command line (includes running from Ant) - see * below, this relies on a *[TuscanyLauncher]* - Webapp (Generic) - construct a WAR with appropriately configured web.xml using * [TuscanyServletFilter]* or *[ TuscanyContextListener]* as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. *User Type 3 * Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: - Tooling - dependency on Tuscany library from *[Eclipse Plugin]* - dependency on Tuscany modules from distribution. Set up manually - dependency on Tuscany modules from local maven repo (mvn -Peclipse) - Command line(includes running from Ant) - java MyClass.jar - Specify
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws simonsl...@googlemail.comwrote: On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng enjoyj...@gmail.comwrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond *From:* Simon Laws simonsl...@googlemail.com *Sent:* Tuesday, January 13, 2009 7:20 AM *To:* dev@tuscany.apache.org *Subject:* Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon *User Type 1:* Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: - Contribution Zip/Jar/Directory - Use container specific mechanisms for loading contribution - Webapp (SCA) - construct a WAR and contribute to SCA enable container - Enterprise (SCA) - construct an EAR and contribute to SCA enabled container *User Type 2: * Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: - Tooling - Eclipse plugin, right click on composite file in contribution project. Relies on [*Eclipse Plugin*] - Command line (includes running from Ant) - see * below, this relies on a *[TuscanyLauncher]* - Webapp (Generic) - construct a WAR with appropriately configured web.xml using * [TuscanyServletFilter]* or *[ TuscanyContextListener]* as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. *User Type 3 * Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: - Tooling - dependency on Tuscany library from *[Eclipse Plugin]* - dependency on Tuscany modules from distribution. Set up manually - dependency on Tuscany modules from local maven repo (mvn -Peclipse) - Command line(includes running from Ant) - java MyClass.jar - Specify the required jars on the classpath either manually or with *[tuscany-sca-manifest.jar]* - Mvn - include
Re: [2.x] [DISCUSS] Tuscany runtime launching
Seperating this one out to its own email as its a bit long... On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws simonsl...@googlemail.comwrote: Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. I agree with these launcher comments, but using a launcher does have some benefits so here's a proposal for if we do end up using one: Separate out the launcher functionality to its own module which focuses purely on setting up a classpath and calling some main class, with no code to do anything like calling Tuscany specific Node APIs etc, and have that launcher configured by external config files which define the classpath and main class to call. Then provide several config files for the various environments and runtimes we want to support. The launcher jar and configfiles would go in separate bin folder in the distribution (or maybe the top level folder), and like the old tuscany manifest jar the launcher jar name wouldn't include a version number to make it simple and consistent across releases. So a distribution would look something like: tuscany-2.0/ bin/launcher.jar bin/default.config bin/osgi.config bin/manager.config bin/myCustomConfigThatUsesJMSandJDK6.config lib/... samples/... To run something like the calculator sample with the standalone runtimeyou'd do: java -jar bin/launcher.jar sample.calculator.jar which would use the default.config and to use one of the other config files you'd set a property or use an additional parameter,eg: java -jar bin/launcher.jar osgisample.calculator.jar. The config files could be simple Java properties files defining the jars and folders to add to the classpath and the class with the main method to run, and support some simple wildcards, eg: mainClass=org.apache.tuscany.sca.node.NodeMain classpath1=../lib/core/* classpath2=../lib/jetty/* classpath3=../lib/webservices/* Could even be a bit more fancy and support some simple conditionals in the classpath properties to enable only setting a classpath for specific JDKlevels etc. The advantages of this approach is that its parameterized and its no longer mysterious what the launcher is doing. It also makes things very flexible and easy to customize the runtime environment without changing any code, and it goes along with the modularity story by not munging the launcher and tuscany node startup code into one module. What we're trying to do is common for many other projects, I've looked at a whole bunch to see what they do, there are several common approaches from using bat scripts, proprietary launchers to 3rd party launcher projects etc, this particular approach seems best to me, its based on the approach used by Jetty: http://docs.codehaus .org/display/JETTY/A+look+at+the+start.jar+mechanism ...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng enjoyj...@gmail.com wrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond *From:* Simon Laws simonsl...@googlemail.com *Sent:* Tuesday, January 13, 2009 7:20 AM *To:* dev@tuscany.apache.org *Subject:* Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon *User Type 1:* Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: - Contribution Zip/Jar/Directory - Use container specific mechanisms for loading contribution - Webapp (SCA) - construct a WAR and contribute to SCA enable container - Enterprise (SCA) - construct an EAR and contribute to SCA enabled container *User Type 2: * Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: - Tooling - Eclipse plugin, right click on composite file in contribution project. Relies on [*Eclipse Plugin*] - Command line (includes running from Ant) - see * below, this relies on a *[TuscanyLauncher]* - Webapp (Generic) - construct a WAR with appropriately configured web.xml using * [TuscanyServletFilter]* or *[ TuscanyContextListener]* as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. *User Type 3 * Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: - Tooling - dependency on Tuscany library from *[Eclipse Plugin]* - dependency on Tuscany modules from distribution. Set up manually - dependency on Tuscany modules from local maven repo (mvn -Peclipse) - Command line(includes running from Ant) - java MyClass.jar - Specify the required jars on the classpath either manually or with *[tuscany-sca-manifest.jar]* - Mvn - include a dependency on appropriate *[Tuscany feature distributions/modules] * - OSGi - Construct a bundle which uses some Tuscany classes. Add all the appropriate tuscany jars and dependencies to your OSGi environment. Start
Re: [2.x] [DISCUSS] Tuscany runtime launching
Hi, I have created a wiki page [1] to list the different cases you described. I hope it will become part of the user guide once we have it agreed and implemented. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Runtime+Launching Thanks, Raymond From: Simon Laws Sent: Friday, January 16, 2009 7:45 AM To: dev@tuscany.apache.org Subject: Re: [2.x] [DISCUSS] Tuscany runtime launching On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng enjoyj...@gmail.com wrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond From: Simon Laws Sent: Tuesday, January 13, 2009 7:20 AM To: dev@tuscany.apache.org Subject: Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon User Type 1: Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: a.. Contribution Zip/Jar/Directory a.. Use container specific mechanisms for loading contribution b.. Webapp (SCA) a.. construct a WAR and contribute to SCA enable container c.. Enterprise (SCA) a.. construct an EAR and contribute to SCA enabled container User Type 2: Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: a.. Tooling a.. Eclipse plugin, right click on composite file in contribution project. Relies on [Eclipse Plugin] b.. Command line (includes running from Ant) a.. see * below, this relies on a [TuscanyLauncher] c.. Webapp (Generic) a.. construct a WAR with appropriately configured web.xml using [TuscanyServletFilter] or [ TuscanyContextListener] as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. User Type 3 Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: a.. Tooling a.. dependency on Tuscany library from [Eclipse Plugin] b.. dependency on Tuscany modules from distribution. Set up manually c.. dependency on Tuscany modules from local maven repo (mvn -Peclipse) b.. Command line(includes running from Ant) a.. java MyClass.jar a.. Specify the required jars on the classpath either manually or with [tuscany-sca-manifest.jar] c.. Mvn a.. include a dependency on appropriate [Tuscany feature
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng enjoyj...@gmail.com wrote: It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond *From:* Simon Laws simonsl...@googlemail.com *Sent:* Tuesday, January 13, 2009 7:20 AM *To:* dev@tuscany.apache.org *Subject:* Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items. Apologies for the slight pause here. I've tried to reorganize the list somewhat based on what people have said, see below. I've tried to note in [] where Tuscany has to deliver some specific support. From my point of view the main point of contention seems to be how we organize command line launching for UT2. - How to support the different options that can be specified. Separate launchers vs parameterized launcher. I probably marginally favour a parameterized purely from the point of view that it gives Tuscany a persona but I haven't considered the technical complications this presents - java -jar vs java -cp We can allow both quite easily but which to document. I find the -far version a bit mysterious so favour -cp but that's just a personal preference. Coming back to Ant's early question this is about finding the way that we think is nest to support these different types of users. Thoughts? Simon *User Type 1:* Wants to run a contribution/composite with not further coding and have a container that already embeds the Tuscany runtime to allow them to do this. Supported mechanisms: - Contribution Zip/Jar/Directory - Use container specific mechanisms for loading contribution - Webapp (SCA) - construct a WAR and contribute to SCA enable container - Enterprise (SCA) - construct an EAR and contribute to SCA enabled container *User Type 2: * Wants to run a contribution/composite with not further coding. I.e. They don't want to write a mainline to start a node instead they want to treat Tuscany as a pre-compiled application. They will have downloaded a binary Tuscany distribution Supported mechanisms: - Tooling - Eclipse plugin, right click on composite file in contribution project. Relies on [*Eclipse Plugin*] - Command line (includes running from Ant) - see * below, this relies on a *[TuscanyLauncher]* - Webapp (Generic) - construct a WAR with appropriately configured web.xml using * [TuscanyServletFilter]* or *[ TuscanyContextListener]* as appropriate. * Command line. There are a number of variables we need to take account of here. OSGi/J2SE Standalone Node/Domain/Node registering with domain Normal/Debug (I just made this up) Two obvious approaches 1/ Different launcher classes to do different things. 2/ One launcher that is parameterized based on what you want it to do. *User Type 3 * Wants to start the runtime from code as they want to embed it for some reason. Their reason could range from just wanting to automate testing right through to wanting to extend some existing software with SCA runtime capabilities. Will have downloaded a binary distribution. The pre-condition here is they have written some kind of mainline that uses Tuscany classes. It could fire up nodes using the NodeFactory or other parts Tuscany such as the model processing. Supported mechanisms: - Tooling - dependency on Tuscany library from *[Eclipse Plugin]* - dependency on Tuscany modules from distribution. Set up manually - dependency on Tuscany modules from local maven repo (mvn -Peclipse) - Command line(includes running from Ant) - java MyClass.jar - Specify the required jars on the classpath either manually or with *[tuscany-sca-manifest.jar]* - Mvn - include a dependency on appropriate *[Tuscany feature distributions/modules
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself And one more here, the TuscanyContextListener. ...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Tue, Jan 13, 2009 at 9:15 AM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself And one more here, the TuscanyContextListener. ...ant Where does that fit Ant? Is that the user thing that looks for contributions being added to a directory? Simon
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Tue, Jan 13, 2009 at 9:17 AM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 9:15 AM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself And one more here, the TuscanyContextListener. ...ant Where does that fit Ant? Is that the user thing that looks for contributions being added to a directory? Simon Its a webapp ContextListener that starts/stops the Tuscany runtime. If you are not using HTTP based services you wont define a TuscanyServletFilter so the runtime wont get started, or if you want non-HTTP services to be started before an HTTP request is recieved. So say you have services using the JMS or RMI binding then you need to use the uscanyContextListener. If you define both the TuscanyContextListener and the TuscanyServletFilter then the TuscanyServletFilter uses the runtime instance started by the ContextListener. ...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Tue, Jan 13, 2009 at 9:31 AM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 9:24 AM, ant elder antel...@apache.org wrote: On Tue, Jan 13, 2009 at 9:17 AM, Simon Laws simonsl...@googlemail.comwrote: On Tue, Jan 13, 2009 at 9:15 AM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself And one more here, the TuscanyContextListener. ...ant Where does that fit Ant? Is that the user thing that looks for contributions being added to a directory? Simon Its a webapp ContextListener that starts/stops the Tuscany runtime. If you are not using HTTP based services you wont define a TuscanyServletFilter so the runtime wont get started, or if you want non-HTTP services to be started before an HTTP request is recieved. So say you have services using the JMS or RMI binding then you need to use the uscanyContextListener. If you define both the TuscanyContextListener and the TuscanyServletFilter then the TuscanyServletFilter uses the runtime instance started by the ContextListener. ...ant Thanks Ant, It sounds like the user has to make a decision here when configuring the web.xml based on which bindings are used in the composite file. Or do they always specify a context listener and then add a filter if required. I only see the filter used in a quick glance at some of the web app samples. Simon Thats right the user can choose, so if they know its ok to only have the runtime started when a first http request comes in then (as most it is for the tuscany samples) then you don't need to use the ContextListener, if you know you're not using any HTTP based services then you don't need to define the Filter. If you don't want to think about it just define them both. We've the start of some doc on this at http://tuscany.apache.org/sca-java-web-applications.html ...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items.
Re: [2.x] [DISCUSS] Tuscany runtime launching
It's a different way to classify how an SCA composite application can be launched using Tuscany runtime. Thanks, Raymond From: Simon Laws Sent: Tuesday, January 13, 2009 7:20 AM To: dev@tuscany.apache.org Subject: Re: [2.x] [DISCUSS] Tuscany runtime launching In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. Is this covered by User/Command line without writing a mainline ? 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Is this covered by User or Embedder/Command line with a mainline that uses some Tuscany classes or the lanucher Am trying understand if what you have are new items or just a different way of classifying the items.
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself Container. With JEE support a user may want to contribute our composite as par of a WAR, EAR etc If the container embeds Tuscany then it's up to the container to ensure that SCA contributions can be run Mvn again assuming there is a mainline that fires up a node launcher include a dependency on a Tuscany launcher distribtion Domain java -jar nodeLauncher.jar domain and then add the contribution to the domain, configure a node and start it OSGi add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Need a bundle that will launch the domain, a node with a contribution or some other service that launches a node Tuscany Embedder === Here the embedder wants to use the Tuscany API behind the launcher in order to exploit some individual parts of the Tuscany code base. The embedder still treats Tuscany as a library so they still need to download a distribution. However the embedder must set up the classpath more explicitly IDE(Eclipse) Project with some kind of mainline that uses some Tuscany classes dependency on Tuscany library dependency on Tuscany modules from distribution. Set up manually. dependency on Tuscany modules from local maven repo (mvn -Peclipse) Command line with a mainline that uses some Tuscany classes java MyClass.jar Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Mvn again with a mainline that uses some Tuscany classes include a dependency on a Tuscany distribution OSGi the embedder will construct a bundle which uses some Tuscany classes add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Tuscany Developer === A developer of the Tuscany infrastructure will first check out the source code from svn. The developer may be acting as a user (running samples) or as an embedder (running unit ot itests). Primarily a developer will use an IDE with the tuscany modules loaded or a mvn compile. IDE(Eclipse) - the important thing here is to have a dependency on the classes in the Eclipse workspace so any changes are picked up as they happen without a mvn compile. Project with some kind of mainline that uses either launcher or other Tuscany classes dependency on Tuscany modules from workspace (mvn -Peclipse) Mvn again with a mainline that uses either launcher or other Tuscany classes include a dependency on a Tuscany distribution Simon One comment right away is that this mentions node launcher a lot but most of the time in previous release we haven't used a launcher we use the SCADomain or the SCA NodeFactory, but before getting bogged down in those details what is it you
Re: [2.x] [DISCUSS] Tuscany runtime launching
On Fri, Jan 9, 2009 at 3:45 PM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself Container. With JEE support a user may want to contribute our composite as par of a WAR, EAR etc If the container embeds Tuscany then it's up to the container to ensure that SCA contributions can be run Mvn again assuming there is a mainline that fires up a node launcher include a dependency on a Tuscany launcher distribtion Domain java -jar nodeLauncher.jar domain and then add the contribution to the domain, configure a node and start it OSGi add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Need a bundle that will launch the domain, a node with a contribution or some other service that launches a node Tuscany Embedder === Here the embedder wants to use the Tuscany API behind the launcher in order to exploit some individual parts of the Tuscany code base. The embedder still treats Tuscany as a library so they still need to download a distribution. However the embedder must set up the classpath more explicitly IDE(Eclipse) Project with some kind of mainline that uses some Tuscany classes dependency on Tuscany library dependency on Tuscany modules from distribution. Set up manually. dependency on Tuscany modules from local maven repo (mvn -Peclipse) Command line with a mainline that uses some Tuscany classes java MyClass.jar Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Mvn again with a mainline that uses some Tuscany classes include a dependency on a Tuscany distribution OSGi the embedder will construct a bundle which uses some Tuscany classes add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Tuscany Developer === A developer of the Tuscany infrastructure will first check out the source code from svn. The developer may be acting as a user (running samples) or as an embedder (running unit ot itests). Primarily a developer will use an IDE with the tuscany modules loaded or a mvn compile. IDE(Eclipse) - the important thing here is to have a dependency on the classes in the Eclipse workspace so any changes are picked up as they happen without a mvn compile. Project with some kind of mainline that uses either launcher or other Tuscany classes dependency on Tuscany modules from workspace (mvn -Peclipse) Mvn again with a mainline that uses either launcher or other Tuscany classes include a dependency on a Tuscany distribution Simon One comment right away is that this mentions node launcher a lot but most of the time in previous release we haven't used a launcher we use the SCADomain or the
Re: [2.x] [DISCUSS] Tuscany runtime launching
Is what Simon have written a good summary for 1.x user doc? This is missing from the doc. Why is domain in a separate line of its own if it applies to all those environments? On Fri, Jan 9, 2009 at 8:00 AM, Simon Laws simonsl...@googlemail.comwrote: On Fri, Jan 9, 2009 at 3:45 PM, ant elder ant.el...@gmail.com wrote: On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws simonsl...@googlemail.comwrote: Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself Container. With JEE support a user may want to contribute our composite as par of a WAR, EAR etc If the container embeds Tuscany then it's up to the container to ensure that SCA contributions can be run Mvn again assuming there is a mainline that fires up a node launcher include a dependency on a Tuscany launcher distribtion Domain java -jar nodeLauncher.jar domain and then add the contribution to the domain, configure a node and start it OSGi add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Need a bundle that will launch the domain, a node with a contribution or some other service that launches a node Tuscany Embedder === Here the embedder wants to use the Tuscany API behind the launcher in order to exploit some individual parts of the Tuscany code base. The embedder still treats Tuscany as a library so they still need to download a distribution. However the embedder must set up the classpath more explicitly IDE(Eclipse) Project with some kind of mainline that uses some Tuscany classes dependency on Tuscany library dependency on Tuscany modules from distribution. Set up manually. dependency on Tuscany modules from local maven repo (mvn -Peclipse) Command line with a mainline that uses some Tuscany classes java MyClass.jar Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Mvn again with a mainline that uses some Tuscany classes include a dependency on a Tuscany distribution OSGi the embedder will construct a bundle which uses some Tuscany classes add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Tuscany Developer === A developer of the Tuscany infrastructure will first check out the source code from svn. The developer may be acting as a user (running samples) or as an embedder (running unit ot itests). Primarily a developer will use an IDE with the tuscany modules loaded or a mvn compile. IDE(Eclipse) - the important thing here is to have a dependency on the classes in the Eclipse workspace so any changes are picked up as they happen without a mvn compile. Project with some kind of mainline that uses either launcher or other Tuscany classes dependency on Tuscany modules from workspace (mvn -Peclipse) Mvn again with a mainline that uses either launcher
Re: [2.x] [DISCUSS] Tuscany runtime launching
Why is domain in a separate line of its own if it applies to all those environments? On this list I mean running the separate domain manager which currently we only have to do if we want to run distributed.
Re: [2.x] [DISCUSS] Tuscany runtime launching
Good summary. In addition to the various environment, there are two styles to launch an SCA composite application: 1) The Tuscany runtime is not on the classpath and the SCA application doesn't call any Tuscany APIs except the SCA Java annotations and APIs. 2) The Tuscany runtime (or a subset) is on the classpath and the SCA application calls some sort of Tuscany APIs to bootstrap the Tuscany runtime. Thanks, Raymond From: Simon Laws Sent: Friday, January 09, 2009 7:13 AM To: tuscany-dev Subject: [2.x] [DISCUSS] Tuscany runtime launching Some mechanisms we have used to date. Turns out to be quite long and I expect there are more I have overlooked. Any help to orangize/rationlize this lot is appreciated. Tuscany User == Someone who wants to use Tuscany to run a composite in a contribution they have constructed. They will first have to get a Tuscany distribution Download and unpack a distribution Include mvn dependency on a distribution (I guess they could depend on individual modules but it would be cleaner to have a distribution dependency) Install the Tuscany Eclipse plugin Get a container that embeds the Tuscany runtime They treat Tuscany as a library and can run their contribution in a number of ways IDE(Eclipse) Contribution only project right click on composite (fires up the domain behind the scenes) - depends on Tuscany Eclipse plugin configure runAs to fire up the launcher from Tuscany library Project with some kind of mainline that manually runs the lanucher, e.g. JUnit dependency on Tuscany library dependency on just launcher modules and configure runAs with $TUSCANY-HOME Command line without writing a mainline java -jar nodeLauncher.jar compositeURI contributionLocation Run with direct reference to distribution directory Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Command line with a mainline that fires up a node launcher java MyClass.jar Specify location of launcher jar and distribution directory via $TUSCANY-HOME (?) Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar There are some distinctions here as you may not want your client code to share the same environment as the Tuscany runtime even though the two are running in the same VM Host-webapp, exploiting TuscanyServletFilter Set up the servlet filter and include the Tuscany distribution in the webapp itself Container. With JEE support a user may want to contribute our composite as par of a WAR, EAR etc If the container embeds Tuscany then it's up to the container to ensure that SCA contributions can be run Mvn again assuming there is a mainline that fires up a node launcher include a dependency on a Tuscany launcher distribtion Domain java -jar nodeLauncher.jar domain and then add the contribution to the domain, configure a node and start it OSGi add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Need a bundle that will launch the domain, a node with a contribution or some other service that launches a node Tuscany Embedder === Here the embedder wants to use the Tuscany API behind the launcher in order to exploit some individual parts of the Tuscany code base. The embedder still treats Tuscany as a library so they still need to download a distribution. However the embedder must set up the classpath more explicitly IDE(Eclipse) Project with some kind of mainline that uses some Tuscany classes dependency on Tuscany library dependency on Tuscany modules from distribution. Set up manually. dependency on Tuscany modules from local maven repo (mvn -Peclipse) Command line with a mainline that uses some Tuscany classes java MyClass.jar Specify the required jars on the classpath either manually or with tuscany-sca-manifest.jar Mvn again with a mainline that uses some Tuscany classes include a dependency on a Tuscany distribution OSGi the embedder will construct a bundle which uses some Tuscany classes add all the tuscany jars and dependencies (PDETarget?) to your OSGi environment Tuscany Developer === A developer of the Tuscany infrastructure will first check out the source code from svn. The developer may be acting as a user (running samples) or as an embedder (running unit ot itests). Primarily a developer will use an IDE with the tuscany modules loaded or a mvn compile. IDE(Eclipse) - the important thing here is to have a dependency on the classes in the Eclipse workspace so any changes are picked up as they happen without a mvn compile. Project with some kind of mainline that uses either launcher or other Tuscany classes dependency on
