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 <[email protected]> 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" <[email protected]>
> Sent: Wednesday, January 21, 2009 9:00 AM
> To: <[email protected]>; <[email protected]>
> 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 <[email protected]> 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/
>>
>
>
