On Tue, Jan 13, 2009 at 9:17 AM, Simon Laws <[email protected]>wrote:
> > > On Tue, Jan 13, 2009 at 9:15 AM, ant elder <[email protected]> wrote: > >> >> >> On Fri, Jan 9, 2009 at 3:13 PM, Simon Laws <[email protected]>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
