You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/01/09 16:13:12 UTC
[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 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
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Simon Laws <si...@googlemail.com>.
>
> 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
Posted by haleh mahbod <hm...@gmail.com>.
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 <si...@googlemail.com>wrote:
>
>
> On Fri, Jan 9, 2009 at 3:45 PM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>> 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 want to get from this thread so we know what to focus
>> discussion on? Is it just to get a list of all the ways we've done this, or
>> to come up with better ways of doing all these things?
>>
>> ...ant
>>
>>
> 1/ I'd like to define the optimal way of doing these things
> 2/ I'd like to learn from what has gone before. There are several
> subtleties that I wouldn't want to overlook and which I personally wouldn't
> have considered if I sat down with a clean page.
>
> Simon
>
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 9, 2009 at 3:45 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
>
>> 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 want to get from this thread so we know what to focus
> discussion on? Is it just to get a list of all the ways we've done this, or
> to come up with better ways of doing all these things?
>
> ...ant
>
>
1/ I'd like to define the optimal way of doing these things
2/ I'd like to learn from what has gone before. There are several subtleties
that I wouldn't want to overlook and which I personally wouldn't have
considered if I sat down with a clean page.
Simon
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@gmail.com>.
On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
> 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 want to get from this thread so we know what to focus
discussion on? Is it just to get a list of all the ways we've done this, or
to come up with better ways of doing all these things?
...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@apache.org>.
On Mon, Jan 19, 2009 at 3:32 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Sat, Jan 17, 2009 at 10:01 AM, ant elder <an...@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 <si...@googlemail.com>wrote:
>>
>> 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
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Jan 17, 2009 at 10:01 AM, ant elder <an...@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 <si...@googlemail.com>wrote:
>
> 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 classpathand 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
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@gmail.com>.
Seperating this one out to its own email as its a bit long...
On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws <si...@googlemail.com>wrote:
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
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 16, 2009 at 5:48 PM, Raymond Feng <en...@gmail.com> wrote:
> 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 <si...@googlemail.com>
> *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 <en...@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 <si...@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
> the application bundle.
>
>
> *User Type 4 *
>
> Wants to contribute to the Tuscany project or build extensions to Tuscany.
> Will have a source distribution. They may use various means to test
> infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
>
>
> Supported mechanisms:
>
>
>
> -
>
> Tooling
> -
>
> With mainline that uses either the launcher or other Tuscany
> classes include a dependency on the Tuscany loaded classes in the Eclipse
> workspace so any changes are picked up as they happen without a mvn compile.
> This can be achieved by including appropriate Tuscany modules from workspace
> (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely
> on the *[PDE target distribution]* to configure the Eclipse
> evironment.
> -
>
> Mvn
> -
>
> With mainline that uses either the launcher or other Tuscany
> classes include a dependency on *[Tuscany feature
> distributio/modules] *
>
>
> ooo - nice, thx raymond.
Simon
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Raymond Feng <en...@gmail.com>.
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 <en...@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 distributions/modules]
d.. OSGi
a.. Construct a bundle which uses some Tuscany classes. Add all the appropriate tuscany jars and dependencies to your OSGi environment. Start the application bundle.
User Type 4
Wants to contribute to the Tuscany project or build extensions to Tuscany. Will have a source distribution. They may use various means to test infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
Supported mechanisms:
a.. Tooling
a.. With mainline that uses either the launcher or other Tuscany classes include a dependency on the Tuscany loaded classes in the Eclipse workspace so any changes are picked up as they happen without a mvn compile. This can be achieved by including appropriate Tuscany modules from workspace (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely on the [PDE target distribution] to configure the Eclipse evironment.
b.. Mvn
a.. With mainline that uses either the launcher or other Tuscany classes include a dependency on [Tuscany feature distributio/modules]
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Based on the various usage scenarios, I think we need to resolve the issue from the following perspectives:
1) The mode: Managed vs. Unmanaged application
- For managed application, there is a container/launcher which is responsible for bootstrapping the Tuscany runtime and making the runtime available to the application code. This is typically done by a hosting platform specific hook.
* Webapp with a ContextListener or Servlet Filter
* Geronimo/Tuscany plugin
* OSGi extender with BundleListener or FrameworkListener
* A JSE Launcher
- For unmanaged application, the application itself is responsible for loading the Tuscany runtime. For example, the JSE main() , the JUNIT testcase or OSGi activator that call the Tuscany Node API.
2) The configuration: Where are the Tuscany runtime jars located? What contributions are required? What deployable composites should be activated?
- From the application classpath (for example, packaging all the Tuscany jars in the WAR)
- From the container classpath (for example, the Geronimo/Tuscany plugin or deep Tomcat integration)
- From some configuration, for example, set the TUSCANY_HOME system property or parameter in web.xml.
3) The client model: How do we make the SCA Node and/or services available to the application code if it's started by the container hook? We need to find a way to access the SCA services in the application. This is the entry point to the SCA domain from outside world.
* Lookup the SCA Node from JNDI, ServletContext or other registry, and then call Node.getService(...)
* Dependency Injection, for example, add @Reference to Java components, EJB or JSP/Servlet
* Via external protocols, for example, a non-SCA client calling into a Web Service or JSONRPC service exposed by SCA components which in turn connects to other SCA components using Dependency Injection or ComponentContext lookup.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, January 19, 2009 7:41 AM
To: dev@tuscany.apache.org ; antelder@apache.org
Subject: Re: [2.x] [DISCUSS] Tuscany runtime launching
[[snip]]
I think it boils down to three main options;
1 - a launcher to support running tuscany in the "command line" style environments we have supported
real command line (starting nodes and domain)
test code (run from ant, maven or eclipse)
2 - web app support, TuscanyServletFilter/ContextListener
3 - Eclipse plugin for "right click" support
The user is also able to use the SPI directly but then they have to manually specify the classpath, although we may give them some help with some aggregate (manifest?) jars.
Simon
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jan 19, 2009 at 9:59 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Sat, Jan 17, 2009 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <en...@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 <si...@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 the application bundle.
>>>>
>>>>
>>>> *User Type 4 *
>>>>
>>>> Wants to contribute to the Tuscany project or build extensions to
>>>> Tuscany. Will have a source distribution. They may use various means to test
>>>> infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
>>>>
>>>>
>>>> Supported mechanisms:
>>>>
>>>>
>>>>
>>>> -
>>>>
>>>> Tooling
>>>> -
>>>>
>>>> With mainline that uses either the launcher or other Tuscany
>>>> classes include a dependency on the Tuscany loaded classes in the Eclipse
>>>> workspace so any changes are picked up as they happen without a mvn compile.
>>>> This can be achieved by including appropriate Tuscany modules from workspace
>>>> (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely
>>>> on the *[PDE target distribution]* to configure the Eclipse
>>>> evironment.
>>>> -
>>>>
>>>> Mvn
>>>> -
>>>>
>>>> With mainline that uses either the launcher or other Tuscany
>>>> classes include a dependency on *[Tuscany feature
>>>> distributio/modules] *
>>>>
>>>>
>>>>
>>> oops, pressed send too early. In my first comment about deciding what the
>>> command line approach should be I should have also added that someone
>>> mentioned having a script like Tomcat does. So I guess the question should
>>> be something like.
>>>
>>> java -jar vs java -cp vs tuscany
>>>
>>> Simon
>>>
>>
>> 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.
>
>
>>
>>
>> A couple of places this mentions that Ant scripts would use the
>> TuscanyLauncher, why would you do that? The Ant build can setup a classpath
>> and call any main class itself can't it?
>
>
> And setting up a classpath and calling a main is included under type2. But
> it can also call a launcher.
>
>>
>>
>> This thread has been about all the different mechanisms we have used to
>> date to start a runtime and there's quite a lot of ways. It would make
>> things simpler of we could reduce all the different options so do we really
>> need to support all these again in 2.x? For example some things are: Do we
>> really need "java -cp", a launcher, Ant, and mvn options for running
>> standalone? Do we even really need both the standalone runtime and the OSGi
>> runtime? The vast majority of our users use the webapp runtime not the
>> standalone runtime, not sure if anyone would really use the standalone stuff
>> in production, and now we're putting a lot of focus on the OSGi runtime so
>> we could use that instead of the old standalone runtime for most things
>> making the OSGi runtime our primary environment outside of a webapp/jee.
>
>
> Now we have a list of scenarios that I'm not hearing people say is widely
> inaccurate we can boil it down to what we actually want to support. I'll
> comment more explicitly in a bit.
>
>
>>
>>
>> ...ant
>>
>>
>>
>
I think it boils down to three main options;
1 - a launcher to support running tuscany in the "command line" style
environments we have supported
real command line (starting nodes and domain)
test code (run from ant, maven or eclipse)
2 - web app support, TuscanyServletFilter/ContextListener
3 - Eclipse plugin for "right click" support
The user is also able to use the SPI directly but then they have to manually
specify the classpath, although we may give them some help with some
aggregate (manifest?) jars.
Simon
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@apache.org>.
On Mon, Jan 19, 2009 at 9:59 AM, Simon Laws <si...@googlemail.com>wrote:
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
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Jan 17, 2009 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <en...@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 <si...@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
>>> the application bundle.
>>>
>>>
>>> *User Type 4 *
>>>
>>> Wants to contribute to the Tuscany project or build extensions to
>>> Tuscany. Will have a source distribution. They may use various means to test
>>> infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
>>>
>>>
>>> Supported mechanisms:
>>>
>>>
>>>
>>> -
>>>
>>> Tooling
>>> -
>>>
>>> With mainline that uses either the launcher or other Tuscany
>>> classes include a dependency on the Tuscany loaded classes in the Eclipse
>>> workspace so any changes are picked up as they happen without a mvn compile.
>>> This can be achieved by including appropriate Tuscany modules from workspace
>>> (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely
>>> on the *[PDE target distribution]* to configure the Eclipse
>>> evironment.
>>> -
>>>
>>> Mvn
>>> -
>>>
>>> With mainline that uses either the launcher or other Tuscany
>>> classes include a dependency on *[Tuscany feature
>>> distributio/modules] *
>>>
>>>
>>>
>> oops, pressed send too early. In my first comment about deciding what the
>> command line approach should be I should have also added that someone
>> mentioned having a script like Tomcat does. So I guess the question should
>> be something like.
>>
>> java -jar vs java -cp vs tuscany
>>
>> Simon
>>
>
> 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.
>
>
> A couple of places this mentions that Ant scripts would use the
> TuscanyLauncher, why would you do that? The Ant build can setup a classpath
> and call any main class itself can't it?
And setting up a classpath and calling a main is included under type2. But
it can also call a launcher.
>
>
> This thread has been about all the different mechanisms we have used to
> date to start a runtime and there's quite a lot of ways. It would make
> things simpler of we could reduce all the different options so do we really
> need to support all these again in 2.x? For example some things are: Do we
> really need "java -cp", a launcher, Ant, and mvn options for running
> standalone? Do we even really need both the standalone runtime and the OSGi
> runtime? The vast majority of our users use the webapp runtime not the
> standalone runtime, not sure if anyone would really use the standalone stuff
> in production, and now we're putting a lot of focus on the OSGi runtime so
> we could use that instead of the old standalone runtime for most things
> making the OSGi runtime our primary environment outside of a webapp/jee.
Now we have a list of scenarios that I'm not hearing people say is widely
inaccurate we can boil it down to what we actually want to support. I'll
comment more explicitly in a bit.
>
>
> ...ant
>
>
>
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@gmail.com>.
On Fri, Jan 16, 2009 at 3:49 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <en...@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 <si...@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
>> the application bundle.
>>
>>
>> *User Type 4 *
>>
>> Wants to contribute to the Tuscany project or build extensions to Tuscany.
>> Will have a source distribution. They may use various means to test
>> infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
>>
>>
>> Supported mechanisms:
>>
>>
>>
>> -
>>
>> Tooling
>> -
>>
>> With mainline that uses either the launcher or other Tuscany
>> classes include a dependency on the Tuscany loaded classes in the Eclipse
>> workspace so any changes are picked up as they happen without a mvn compile.
>> This can be achieved by including appropriate Tuscany modules from workspace
>> (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely
>> on the *[PDE target distribution]* to configure the Eclipse
>> evironment.
>> -
>>
>> Mvn
>> -
>>
>> With mainline that uses either the launcher or other Tuscany
>> classes include a dependency on *[Tuscany feature
>> distributio/modules] *
>>
>>
>>
> oops, pressed send too early. In my first comment about deciding what the
> command line approach should be I should have also added that someone
> mentioned having a script like Tomcat does. So I guess the question should
> be something like.
>
> java -jar vs java -cp vs tuscany
>
> Simon
>
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.
A couple of places this mentions that Ant scripts would use the
TuscanyLauncher, why would you do that? The Ant build can setup a classpath
and call any main class itself can't it?
This thread has been about all the different mechanisms we have used to date
to start a runtime and there's quite a lot of ways. It would make things
simpler of we could reduce all the different options so do we really need to
support all these again in 2.x? For example some things are: Do we really
need "java -cp", a launcher, Ant, and mvn options for running standalone? Do
we even really need both the standalone runtime and the OSGi runtime? The
vast majority of our users use the webapp runtime not the standalone
runtime, not sure if anyone would really use the standalone stuff in
production, and now we're putting a lot of focus on the OSGi runtime so we
could use that instead of the old standalone runtime for most things making
the OSGi runtime our primary environment outside of a webapp/jee.
...ant
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 16, 2009 at 3:45 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <en...@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 <si...@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
> the application bundle.
>
>
> *User Type 4 *
>
> Wants to contribute to the Tuscany project or build extensions to Tuscany.
> Will have a source distribution. They may use various means to test
> infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
>
>
> Supported mechanisms:
>
>
>
> -
>
> Tooling
> -
>
> With mainline that uses either the launcher or other Tuscany
> classes include a dependency on the Tuscany loaded classes in the Eclipse
> workspace so any changes are picked up as they happen without a mvn compile.
> This can be achieved by including appropriate Tuscany modules from workspace
> (mvn -Peclipse). As we build Tuscany module as bundles using the PDE we rely
> on the *[PDE target distribution]* to configure the Eclipse
> evironment.
> -
>
> Mvn
> -
>
> With mainline that uses either the launcher or other Tuscany
> classes include a dependency on *[Tuscany feature
> distributio/modules] *
>
>
>
oops, pressed send too early. In my first comment about deciding what the
command line approach should be I should have also added that someone
mentioned having a script like Tomcat does. So I guess the question should
be something like.
java -jar vs java -cp vs tuscany
Simon
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jan 13, 2009 at 7:52 PM, Raymond Feng <en...@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 <si...@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
the application bundle.
*User Type 4 *
Wants to contribute to the Tuscany project or build extensions to Tuscany.
Will have a source distribution. They may use various means to test
infrastructure changes including the mechanisms used by User Types 1, 2 & 3.
Supported mechanisms:
-
Tooling
-
With mainline that uses either the launcher or other Tuscany
classes include a dependency on the Tuscany loaded classes in
the Eclipse
workspace so any changes are picked up as they happen without
a mvn compile.
This can be achieved by including appropriate Tuscany modules
from workspace
(mvn -Peclipse). As we build Tuscany module as bundles using
the PDE we rely
on the *[PDE target distribution]* to configure the Eclipse
evironment.
-
Mvn
-
With mainline that uses either the launcher or other Tuscany
classes include a dependency on *[Tuscany feature
distributio/modules] *
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by Raymond Feng <en...@gmail.com>.
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
Posted by Simon Laws <si...@googlemail.com>.
>
>
> 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
Posted by Raymond Feng <en...@gmail.com>.
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 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
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@apache.org>.
On Tue, Jan 13, 2009 at 9:31 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Jan 13, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Tue, Jan 13, 2009 at 9:17 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2009 at 9:15 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>>> 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
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jan 13, 2009 at 9:24 AM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Jan 13, 2009 at 9:17 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Jan 13, 2009 at 9:15 AM, ant elder <an...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>> 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
Re: [2.x] [DISCUSS] Tuscany runtime launching
Posted by ant elder <an...@apache.org>.
On Tue, Jan 13, 2009 at 9:17 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Jan 13, 2009 at 9:15 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>> 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
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jan 13, 2009 at 9:15 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
>
>> 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
Posted by ant elder <an...@gmail.com>.
On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <si...@googlemail.com>wrote:
> 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