You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/01/21 17:55:52 UTC
[2.x] Samples
With all the 2.x changes going on and runtime starting discussion i was
wondering about changing some of our samples so that most samples create
proper SCA contribution jars, they get run by deploying the contribution to
a runtime, they wouldn't include the client impl which invokes the sample
within the contribution jar, and maybe also have samples use the
contributions from other samples. It would need a launcher if we did it that
way (like what is being discussed on the runtime launching thread), and we'd
need separate client samples.
It might make the very simplest samples slightly more complicated, but it
makes the sample contributions more reusable across the various runtime
environments and would demonstrate how to use domains with multiple
contributions and composites and how to swap around different binding and
implementation types.
I'm in two minds if it would be better than the current approach, what do
others think?
...ant
Re: [2.x] Samples
Posted by ant elder <an...@apache.org>.
On Wed, Feb 4, 2009 at 12:17 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Jan 22, 2009 at 9:56 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 8:46 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Thu, Jan 22, 2009 at 7:29 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>> I think we're both suggesting the same things just with different
>>>> terminology. You're using the managed versus unmanaged distinction as to
>>>> whether or not the sample starts up a runtime itself or not right, so a
>>>> "managed" sample is what I'd called the proper SCA contributions which get
>>>> deployed to some runtime as a separate step. That separate step makes it
>>>> slightly more complicated but its minimal complexity and would be consistent
>>>> across the samples, and doing it this way makes the sample more focused on
>>>> what its trying to show - how to write a Java component, how to use a web
>>>> service binding, etc - and doesn't mix the code for starting a runtime and
>>>> invoking a service into the sample code which I think makes them clearer.
>>>>
>>>> ...ant
>>>>
>>>>
>>>> On Wed, Jan 21, 2009 at 7:46 PM, Raymond Feng <en...@gmail.com>wrote:
>>>>
>>>>> I would like to see two types of samples:
>>>>>
>>>>> 1) Managed: The composite application is developed as one or more
>>>>> contributions. There is no explicit code to bootstrap the Tuscany runtime in
>>>>> the application. A launcher is used to launch the "pure" SCA application.
>>>>>
>>>>> 2) Unmanaged: The application has a main() (or other entry point based
>>>>> on the hosting environment such as an OSGi activator) to bootstrap the
>>>>> Tuscany runtime and access the SCA services.
>>>>>
>>>>> [1]
>>>>> http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
>>>>>
>>>>> Thanks,
>>>>> Raymond
>>>>>
>>>>> --------------------------------------------------
>>>>> From: "Luciano Resende" <lu...@gmail.com>
>>>>> Sent: Wednesday, January 21, 2009 9:00 AM
>>>>> To: <de...@tuscany.apache.org>; <an...@apache.org>
>>>>> Subject: Re: [2.x] Samples
>>>>>
>>>>>
>>>>> As you mentioned, this might make our samples more complex then
>>>>>> expected from a new user.
>>>>>>
>>>>>> What would be the user experience here ? Maybe we could do something
>>>>>> with the demos, that are already more complex and try to demonstrate a
>>>>>> more realistic user scenario ?
>>>>>>
>>>>>> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> With all the 2.x changes going on and runtime starting discussion i
>>>>>>> was
>>>>>>> wondering about changing some of our samples so that most samples
>>>>>>> create
>>>>>>> proper SCA contribution jars, they get run by deploying the
>>>>>>> contribution to
>>>>>>> a runtime, they wouldn't include the client impl which invokes the
>>>>>>> sample
>>>>>>> within the contribution jar, and maybe also have samples use the
>>>>>>> contributions from other samples. It would need a launcher if we did
>>>>>>> it that
>>>>>>> way (like what is being discussed on the runtime launching thread),
>>>>>>> and we'd
>>>>>>> need separate client samples.
>>>>>>>
>>>>>>> It might make the very simplest samples slightly more complicated,
>>>>>>> but it
>>>>>>> makes the sample contributions more reusable across the various
>>>>>>> runtime
>>>>>>> environments and would demonstrate how to use domains with multiple
>>>>>>> contributions and composites and how to swap around different binding
>>>>>>> and
>>>>>>> implementation types.
>>>>>>>
>>>>>>> I'm in two minds if it would be better than the current approach,
>>>>>>> what do
>>>>>>> others think?
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Luciano Resende
>>>>>> Apache Tuscany, Apache PhotArk
>>>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>>>>> http://lresende.blogspot.com/
>>>>>>
>>>>>
>>>>>
>>>>
>>> I would like the focus to be on what Raymond calls "Managed". I.e. we
>>> have samples that rely on the JSE launcher, the OSGi lanucher, the webapp
>>> "launcher" etc. We should have some samples that use the node launcher or
>>> factory directly to demonstrate the local sca binding in use from a main()
>>> method but I think these should be in the minority whereas at the moment
>>> nearly all the samples are done this way.
>>>
>>> Simon
>>>
>>
>> Yep thats exactly what i think too. So most samples would be demonstrating
>> SCA features and therefore be SCA contributions, some other samples would be
>> demonstrating Tuscany specific things like how to start different runtime
>> environments or get access to the local domain services etc.
>>
>> ...ant
>>
>>
> This is being tracked at TUSCANY-2805. A quick update on various realted
> points. I'm using the binding-ws-calculator sample as the test case for
> this at the moment.
>
> managed vs unmanaged.
>
> there has been discussion, and I believe agreement, here that we want to
> show many more "managed" samples where a launcher is given a contribution as
> an alternative to using the node API from a JSE client. The original plan
> was to use @Init methods to kick the sample off but we await news from OASIS
> on @PostInit before we can go this direction [1]. In the mean time I've
> switched binding-ws-calculator back to being driven by a JSE client. If
> @PostInit doesn't work out we could start two processes for the sample, one
> that runs the composite and a separate client that prods it.
>
> build.xml
>
> I've produced a new build.xml [2] which takes the basic build.xml from the
> rmi samples, adds a run target and does away with the common-build.xml
>
> sample naming
>
> I prefer binding-ws-calculator to calculator-binding-ws as the emphasis is
> on binding-ws rather that on calculator. It would be better to have
> consistent sample names but I want some kind of agreement between us to
> either stay with what we had in 1.x or move to the scheme I'm proposing or
> something else.
>
> samples testing
>
> I'm working on itest/samples to run the samples as though they were being
> run from the binary distribution.
>
> Comments on any of this most welcome.
>
> Simon
>
> [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg04911.html
> [3]
> http://svn.apache.org/repos/asf/tuscany/java/sca/samples/binding-ws-calculator/build.xml
>
I like the build.xml's and the sample itests, that will be really good for
maintaining the stability of the samples.
Don't really mind either way with the sample names, the new way is a bit
more wordy but at least it keeps samples grouped together so eg all ws ones
would be next to each other when looking at a directory list.
...ant
Re: [2.x] Samples
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jan 22, 2009 at 9:56 AM, ant elder <an...@apache.org> wrote:
>
>
> On Thu, Jan 22, 2009 at 8:46 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Jan 22, 2009 at 7:29 AM, ant elder <an...@gmail.com> wrote:
>>
>>> I think we're both suggesting the same things just with different
>>> terminology. You're using the managed versus unmanaged distinction as to
>>> whether or not the sample starts up a runtime itself or not right, so a
>>> "managed" sample is what I'd called the proper SCA contributions which get
>>> deployed to some runtime as a separate step. That separate step makes it
>>> slightly more complicated but its minimal complexity and would be consistent
>>> across the samples, and doing it this way makes the sample more focused on
>>> what its trying to show - how to write a Java component, how to use a web
>>> service binding, etc - and doesn't mix the code for starting a runtime and
>>> invoking a service into the sample code which I think makes them clearer.
>>>
>>> ...ant
>>>
>>>
>>> On Wed, Jan 21, 2009 at 7:46 PM, Raymond Feng <en...@gmail.com>wrote:
>>>
>>>> I would like to see two types of samples:
>>>>
>>>> 1) Managed: The composite application is developed as one or more
>>>> contributions. There is no explicit code to bootstrap the Tuscany runtime in
>>>> the application. A launcher is used to launch the "pure" SCA application.
>>>>
>>>> 2) Unmanaged: The application has a main() (or other entry point based
>>>> on the hosting environment such as an OSGi activator) to bootstrap the
>>>> Tuscany runtime and access the SCA services.
>>>>
>>>> [1]
>>>> http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> --------------------------------------------------
>>>> From: "Luciano Resende" <lu...@gmail.com>
>>>> Sent: Wednesday, January 21, 2009 9:00 AM
>>>> To: <de...@tuscany.apache.org>; <an...@apache.org>
>>>> Subject: Re: [2.x] Samples
>>>>
>>>>
>>>> As you mentioned, this might make our samples more complex then
>>>>> expected from a new user.
>>>>>
>>>>> What would be the user experience here ? Maybe we could do something
>>>>> with the demos, that are already more complex and try to demonstrate a
>>>>> more realistic user scenario ?
>>>>>
>>>>> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> With all the 2.x changes going on and runtime starting discussion i
>>>>>> was
>>>>>> wondering about changing some of our samples so that most samples
>>>>>> create
>>>>>> proper SCA contribution jars, they get run by deploying the
>>>>>> contribution to
>>>>>> a runtime, they wouldn't include the client impl which invokes the
>>>>>> sample
>>>>>> within the contribution jar, and maybe also have samples use the
>>>>>> contributions from other samples. It would need a launcher if we did
>>>>>> it that
>>>>>> way (like what is being discussed on the runtime launching thread),
>>>>>> and we'd
>>>>>> need separate client samples.
>>>>>>
>>>>>> It might make the very simplest samples slightly more complicated, but
>>>>>> it
>>>>>> makes the sample contributions more reusable across the various
>>>>>> runtime
>>>>>> environments and would demonstrate how to use domains with multiple
>>>>>> contributions and composites and how to swap around different binding
>>>>>> and
>>>>>> implementation types.
>>>>>>
>>>>>> I'm in two minds if it would be better than the current approach, what
>>>>>> do
>>>>>> others think?
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Luciano Resende
>>>>> Apache Tuscany, Apache PhotArk
>>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>>>> http://lresende.blogspot.com/
>>>>>
>>>>
>>>>
>>>
>> I would like the focus to be on what Raymond calls "Managed". I.e. we have
>> samples that rely on the JSE launcher, the OSGi lanucher, the webapp
>> "launcher" etc. We should have some samples that use the node launcher or
>> factory directly to demonstrate the local sca binding in use from a main()
>> method but I think these should be in the minority whereas at the moment
>> nearly all the samples are done this way.
>>
>> Simon
>>
>
> Yep thats exactly what i think too. So most samples would be demonstrating
> SCA features and therefore be SCA contributions, some other samples would be
> demonstrating Tuscany specific things like how to start different runtime
> environments or get access to the local domain services etc.
>
> ...ant
>
>
This is being tracked at TUSCANY-2805. A quick update on various realted
points. I'm using the binding-ws-calculator sample as the test case for
this at the moment.
managed vs unmanaged.
there has been discussion, and I believe agreement, here that we want to
show many more "managed" samples where a launcher is given a contribution as
an alternative to using the node API from a JSE client. The original plan
was to use @Init methods to kick the sample off but we await news from OASIS
on @PostInit before we can go this direction [1]. In the mean time I've
switched binding-ws-calculator back to being driven by a JSE client. If
@PostInit doesn't work out we could start two processes for the sample, one
that runs the composite and a separate client that prods it.
build.xml
I've produced a new build.xml [2] which takes the basic build.xml from the
rmi samples, adds a run target and does away with the common-build.xml
sample naming
I prefer binding-ws-calculator to calculator-binding-ws as the emphasis is
on binding-ws rather that on calculator. It would be better to have
consistent sample names but I want some kind of agreement between us to
either stay with what we had in 1.x or move to the scheme I'm proposing or
something else.
samples testing
I'm working on itest/samples to run the samples as though they were being
run from the binary distribution.
Comments on any of this most welcome.
Simon
[1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg04911.html
[3]
http://svn.apache.org/repos/asf/tuscany/java/sca/samples/binding-ws-calculator/build.xml
Re: [2.x] Samples
Posted by ant elder <an...@apache.org>.
On Thu, Jan 22, 2009 at 8:46 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Jan 22, 2009 at 7:29 AM, ant elder <an...@gmail.com> wrote:
>
>> I think we're both suggesting the same things just with different
>> terminology. You're using the managed versus unmanaged distinction as to
>> whether or not the sample starts up a runtime itself or not right, so a
>> "managed" sample is what I'd called the proper SCA contributions which get
>> deployed to some runtime as a separate step. That separate step makes it
>> slightly more complicated but its minimal complexity and would be consistent
>> across the samples, and doing it this way makes the sample more focused on
>> what its trying to show - how to write a Java component, how to use a web
>> service binding, etc - and doesn't mix the code for starting a runtime and
>> invoking a service into the sample code which I think makes them clearer.
>>
>> ...ant
>>
>>
>> On Wed, Jan 21, 2009 at 7:46 PM, Raymond Feng <en...@gmail.com>wrote:
>>
>>> I would like to see two types of samples:
>>>
>>> 1) Managed: The composite application is developed as one or more
>>> contributions. There is no explicit code to bootstrap the Tuscany runtime in
>>> the application. A launcher is used to launch the "pure" SCA application.
>>>
>>> 2) Unmanaged: The application has a main() (or other entry point based on
>>> the hosting environment such as an OSGi activator) to bootstrap the Tuscany
>>> runtime and access the SCA services.
>>>
>>> [1]
>>> http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
>>>
>>> Thanks,
>>> Raymond
>>>
>>> --------------------------------------------------
>>> From: "Luciano Resende" <lu...@gmail.com>
>>> Sent: Wednesday, January 21, 2009 9:00 AM
>>> To: <de...@tuscany.apache.org>; <an...@apache.org>
>>> Subject: Re: [2.x] Samples
>>>
>>>
>>> As you mentioned, this might make our samples more complex then
>>>> expected from a new user.
>>>>
>>>> What would be the user experience here ? Maybe we could do something
>>>> with the demos, that are already more complex and try to demonstrate a
>>>> more realistic user scenario ?
>>>>
>>>> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com> wrote:
>>>>
>>>>> With all the 2.x changes going on and runtime starting discussion i was
>>>>> wondering about changing some of our samples so that most samples
>>>>> create
>>>>> proper SCA contribution jars, they get run by deploying the
>>>>> contribution to
>>>>> a runtime, they wouldn't include the client impl which invokes the
>>>>> sample
>>>>> within the contribution jar, and maybe also have samples use the
>>>>> contributions from other samples. It would need a launcher if we did it
>>>>> that
>>>>> way (like what is being discussed on the runtime launching thread), and
>>>>> we'd
>>>>> need separate client samples.
>>>>>
>>>>> It might make the very simplest samples slightly more complicated, but
>>>>> it
>>>>> makes the sample contributions more reusable across the various runtime
>>>>> environments and would demonstrate how to use domains with multiple
>>>>> contributions and composites and how to swap around different binding
>>>>> and
>>>>> implementation types.
>>>>>
>>>>> I'm in two minds if it would be better than the current approach, what
>>>>> do
>>>>> others think?
>>>>>
>>>>> ...ant
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Luciano Resende
>>>> Apache Tuscany, Apache PhotArk
>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>>> http://lresende.blogspot.com/
>>>>
>>>
>>>
>>
> I would like the focus to be on what Raymond calls "Managed". I.e. we have
> samples that rely on the JSE launcher, the OSGi lanucher, the webapp
> "launcher" etc. We should have some samples that use the node launcher or
> factory directly to demonstrate the local sca binding in use from a main()
> method but I think these should be in the minority whereas at the moment
> nearly all the samples are done this way.
>
> Simon
>
Yep thats exactly what i think too. So most samples would be demonstrating
SCA features and therefore be SCA contributions, some other samples would be
demonstrating Tuscany specific things like how to start different runtime
environments or get access to the local domain services etc.
...ant
Re: [2.x] Samples
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jan 22, 2009 at 7:29 AM, ant elder <an...@gmail.com> wrote:
> I think we're both suggesting the same things just with different
> terminology. You're using the managed versus unmanaged distinction as to
> whether or not the sample starts up a runtime itself or not right, so a
> "managed" sample is what I'd called the proper SCA contributions which get
> deployed to some runtime as a separate step. That separate step makes it
> slightly more complicated but its minimal complexity and would be consistent
> across the samples, and doing it this way makes the sample more focused on
> what its trying to show - how to write a Java component, how to use a web
> service binding, etc - and doesn't mix the code for starting a runtime and
> invoking a service into the sample code which I think makes them clearer.
>
> ...ant
>
>
> On Wed, Jan 21, 2009 at 7:46 PM, Raymond Feng <en...@gmail.com> wrote:
>
>> I would like to see two types of samples:
>>
>> 1) Managed: The composite application is developed as one or more
>> contributions. There is no explicit code to bootstrap the Tuscany runtime in
>> the application. A launcher is used to launch the "pure" SCA application.
>>
>> 2) Unmanaged: The application has a main() (or other entry point based on
>> the hosting environment such as an OSGi activator) to bootstrap the Tuscany
>> runtime and access the SCA services.
>>
>> [1]
>> http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
>>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "Luciano Resende" <lu...@gmail.com>
>> Sent: Wednesday, January 21, 2009 9:00 AM
>> To: <de...@tuscany.apache.org>; <an...@apache.org>
>> Subject: Re: [2.x] Samples
>>
>>
>> As you mentioned, this might make our samples more complex then
>>> expected from a new user.
>>>
>>> What would be the user experience here ? Maybe we could do something
>>> with the demos, that are already more complex and try to demonstrate a
>>> more realistic user scenario ?
>>>
>>> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>> With all the 2.x changes going on and runtime starting discussion i was
>>>> wondering about changing some of our samples so that most samples create
>>>> proper SCA contribution jars, they get run by deploying the contribution
>>>> to
>>>> a runtime, they wouldn't include the client impl which invokes the
>>>> sample
>>>> within the contribution jar, and maybe also have samples use the
>>>> contributions from other samples. It would need a launcher if we did it
>>>> that
>>>> way (like what is being discussed on the runtime launching thread), and
>>>> we'd
>>>> need separate client samples.
>>>>
>>>> It might make the very simplest samples slightly more complicated, but
>>>> it
>>>> makes the sample contributions more reusable across the various runtime
>>>> environments and would demonstrate how to use domains with multiple
>>>> contributions and composites and how to swap around different binding
>>>> and
>>>> implementation types.
>>>>
>>>> I'm in two minds if it would be better than the current approach, what
>>>> do
>>>> others think?
>>>>
>>>> ...ant
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Luciano Resende
>>> Apache Tuscany, Apache PhotArk
>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>> http://lresende.blogspot.com/
>>>
>>
>>
>
I would like the focus to be on what Raymond calls "Managed". I.e. we have
samples that rely on the JSE launcher, the OSGi lanucher, the webapp
"launcher" etc. We should have some samples that use the node launcher or
factory directly to demonstrate the local sca binding in use from a main()
method but I think these should be in the minority whereas at the moment
nearly all the samples are done this way.
Simon
Re: [2.x] Samples
Posted by ant elder <an...@gmail.com>.
I think we're both suggesting the same things just with different
terminology. You're using the managed versus unmanaged distinction as to
whether or not the sample starts up a runtime itself or not right, so a
"managed" sample is what I'd called the proper SCA contributions which get
deployed to some runtime as a separate step. That separate step makes it
slightly more complicated but its minimal complexity and would be consistent
across the samples, and doing it this way makes the sample more focused on
what its trying to show - how to write a Java component, how to use a web
service binding, etc - and doesn't mix the code for starting a runtime and
invoking a service into the sample code which I think makes them clearer.
...ant
On Wed, Jan 21, 2009 at 7:46 PM, Raymond Feng <en...@gmail.com> wrote:
> I would like to see two types of samples:
>
> 1) Managed: The composite application is developed as one or more
> contributions. There is no explicit code to bootstrap the Tuscany runtime in
> the application. A launcher is used to launch the "pure" SCA application.
>
> 2) Unmanaged: The application has a main() (or other entry point based on
> the hosting environment such as an OSGi activator) to bootstrap the Tuscany
> runtime and access the SCA services.
>
> [1]
> http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
>
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Luciano Resende" <lu...@gmail.com>
> Sent: Wednesday, January 21, 2009 9:00 AM
> To: <de...@tuscany.apache.org>; <an...@apache.org>
> Subject: Re: [2.x] Samples
>
>
> As you mentioned, this might make our samples more complex then
>> expected from a new user.
>>
>> What would be the user experience here ? Maybe we could do something
>> with the demos, that are already more complex and try to demonstrate a
>> more realistic user scenario ?
>>
>> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com> wrote:
>>
>>> With all the 2.x changes going on and runtime starting discussion i was
>>> wondering about changing some of our samples so that most samples create
>>> proper SCA contribution jars, they get run by deploying the contribution
>>> to
>>> a runtime, they wouldn't include the client impl which invokes the sample
>>> within the contribution jar, and maybe also have samples use the
>>> contributions from other samples. It would need a launcher if we did it
>>> that
>>> way (like what is being discussed on the runtime launching thread), and
>>> we'd
>>> need separate client samples.
>>>
>>> It might make the very simplest samples slightly more complicated, but it
>>> makes the sample contributions more reusable across the various runtime
>>> environments and would demonstrate how to use domains with multiple
>>> contributions and composites and how to swap around different binding and
>>> implementation types.
>>>
>>> I'm in two minds if it would be better than the current approach, what do
>>> others think?
>>>
>>> ...ant
>>>
>>>
>>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany, Apache PhotArk
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://lresende.blogspot.com/
>>
>
>
Re: [2.x] Samples
Posted by Raymond Feng <en...@gmail.com>.
I would like to see two types of samples:
1) Managed: The composite application is developed as one or more
contributions. There is no explicit code to bootstrap the Tuscany runtime in
the application. A launcher is used to launch the "pure" SCA application.
2) Unmanaged: The application has a main() (or other entry point based on
the hosting environment such as an OSGi activator) to bootstrap the Tuscany
runtime and access the SCA services.
[1] http://markmail.org/message/tbbkihndzzdttzb4?q=Tuscany+runtime+launching
Thanks,
Raymond
--------------------------------------------------
From: "Luciano Resende" <lu...@gmail.com>
Sent: Wednesday, January 21, 2009 9:00 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: [2.x] Samples
> As you mentioned, this might make our samples more complex then
> expected from a new user.
>
> What would be the user experience here ? Maybe we could do something
> with the demos, that are already more complex and try to demonstrate a
> more realistic user scenario ?
>
> On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com> wrote:
>> With all the 2.x changes going on and runtime starting discussion i was
>> wondering about changing some of our samples so that most samples create
>> proper SCA contribution jars, they get run by deploying the contribution
>> to
>> a runtime, they wouldn't include the client impl which invokes the sample
>> within the contribution jar, and maybe also have samples use the
>> contributions from other samples. It would need a launcher if we did it
>> that
>> way (like what is being discussed on the runtime launching thread), and
>> we'd
>> need separate client samples.
>>
>> It might make the very simplest samples slightly more complicated, but it
>> makes the sample contributions more reusable across the various runtime
>> environments and would demonstrate how to use domains with multiple
>> contributions and composites and how to swap around different binding and
>> implementation types.
>>
>> I'm in two minds if it would be better than the current approach, what do
>> others think?
>>
>> ...ant
>>
>>
>
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
Re: [2.x] Samples
Posted by Luciano Resende <lu...@gmail.com>.
As you mentioned, this might make our samples more complex then
expected from a new user.
What would be the user experience here ? Maybe we could do something
with the demos, that are already more complex and try to demonstrate a
more realistic user scenario ?
On Wed, Jan 21, 2009 at 8:55 AM, ant elder <an...@gmail.com> wrote:
> With all the 2.x changes going on and runtime starting discussion i was
> wondering about changing some of our samples so that most samples create
> proper SCA contribution jars, they get run by deploying the contribution to
> a runtime, they wouldn't include the client impl which invokes the sample
> within the contribution jar, and maybe also have samples use the
> contributions from other samples. It would need a launcher if we did it that
> way (like what is being discussed on the runtime launching thread), and we'd
> need separate client samples.
>
> It might make the very simplest samples slightly more complicated, but it
> makes the sample contributions more reusable across the various runtime
> environments and would demonstrate how to use domains with multiple
> contributions and composites and how to swap around different binding and
> implementation types.
>
> I'm in two minds if it would be better than the current approach, what do
> others think?
>
> ...ant
>
>
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/