On Wed, Feb 4, 2009 at 12:17 PM, Simon Laws <[email protected]>wrote:
> > > On Thu, Jan 22, 2009 at 9:56 AM, ant elder <[email protected]> wrote: > >> >> >> On Thu, Jan 22, 2009 at 8:46 AM, Simon Laws <[email protected]>wrote: >> >>> >>> >>> On Thu, Jan 22, 2009 at 7:29 AM, ant elder <[email protected]> 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 <[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/ >>>>>> >>>>> >>>>> >>>> >>> 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
