On Wed, Feb 4, 2009 at 7:00 PM, Simon Laws <[email protected]>wrote:
> > > On Wed, Feb 4, 2009 at 6:39 PM, Raymond Feng <[email protected]> wrote: > >> Hi, >> >> We have cases that we need to stop the node after it's launched or wait >> for a user action (press 'q'). To support that, I added a '-t >> <TTLInMilliSeconds >' option for the JSE and Equinox launcher. >> >> For JSE: >> >> cd distribution\all >> java -jar target\features\manifest.jar >> ..\..\samples\calculator\target\sample-calculator.jar -t 1000 (wait for 1000 >> ms before the node is stopped) >> java -jar target\features\manifest.jar >> ..\..\samples\calculator\target\sample-calculator.jar (wait for user to >> press 'q') >> >> For Equinox: (-config target\features\configuration is optional) >> >> cd distribution\all >> java -jar target\features\equinox-manifest.jar -t 1000 -config >> target\features\configuration >> ..\..\samples\calculator\target\sample-calculator.jar (wait for 1000 ms >> before the node is stopped) >> java -jar target\features\equinox-manifest.jar -config >> target\features\configuration >> ..\..\samples\calculator\target\sample-calculator.jar (wait for user to >> press 'q') >> >> Thanks, >> Raymond >> -------------------------------------------------- >> From: "Raymond Feng" <[email protected]> >> Sent: Tuesday, February 03, 2009 10:10 PM >> To: <[email protected]> >> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - >> /tuscany/java/sca/samples/build-common.xml >> >> I also got the JSE launcher working the same way, for example: >>> >>> java -jar target\features\manifest.jar >>> ..\..\samples\calculator\target\sample-calculator.jar >>> >>> Thanks, >>> Raymond >>> >>> -------------------------------------------------- >>> From: "Luciano Resende" <[email protected]> >>> Sent: Tuesday, February 03, 2009 7:00 PM >>> To: <[email protected]> >>> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - >>> /tuscany/java/sca/samples/build-common.xml >>> >>> On Tue, Feb 3, 2009 at 6:05 PM, Raymond Feng <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I made some progress to use Apache commons-cli to parse the command >>>>> line >>>>> arguments for the Equinox Launcher. It can now process the following >>>>> options: >>>>> >>>>> [-config <equinoxConfiguration>]: The configuration folder for Equinox >>>>> [-c <compositeURI>]: The composite URI >>>>> contribution1 ... contributionN: A list of contribution files or URLs >>>>> >>>>> To try it, you can build the distribution/all first using "mvn clean >>>>> install", then run the following command: >>>>> >>>>> java -jar target\features\equinox-manifest.jar -config >>>>> target\features\configuration >>>>> ..\..\samples\calculator-equinox\target\sample-calculator-equinox.jar >>>>> >>>>> >>>> Looks good... >>>> >>>> A related subject: I don't see a need to have a separate launcher which >>>>> delegates to the JSE or Equinox Launcher. Can we just update the shell >>>>> script to directly call the JSE or Equinox launcher main class? I'm >>>>> working >>>>> on the UNIX script based on the one from Tomcat. >>>>> >>>>> >>>> +1 >>>> >>>> Do we even need a script ? Can't we just document the command line in >>>> the sample README, and provide the necessary ant targets so users can >>>> do : ant run or ant run-managed. This way we avoid exposing the user >>>> that just want to run the sample, to multiple magical layers. >>>> >>>> Thanks, >>>>> Raymond >>>>> >>>>> From: Raymond Feng >>>>> Sent: Friday, January 30, 2009 10:02 AM >>>>> To: [email protected] ; [email protected] >>>>> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - >>>>> /tuscany/java/sca/samples/build-common.xml >>>>> >>>>> >>>>> For c), you can look at the META-INF/MANIFEST.MF inside generated >>>>> "features/equinox-manifest.jar". The classpath contains only the >>>>> entries for >>>>> the equinox launcher. To pass in the configuration (where are the >>>>> bundles) >>>>> to Equinox, use "-Dosgi.configuration.area=features/configuration". >>>>> >>>>> >>>>> From: ant elder >>>>> Sent: Friday, January 30, 2009 9:50 AM >>>>> To: [email protected] >>>>> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - >>>>> /tuscany/java/sca/samples/build-common.xml >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 30, 2009 at 5:38 PM, Raymond Feng <[email protected]> >>>>> wrote: >>>>> >>>>> More comments inline. >>>>> >>>>> Thanks, >>>>> Raymond >>>>> >>>>> >>>>> From: ant elder >>>>> Sent: Friday, January 30, 2009 9:23 AM >>>>> To: [email protected] >>>>> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - >>>>> /tuscany/java/sca/samples/build-common.xml >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <[email protected]> >>>>> wrote: >>>>> >>>>> A few comments: >>>>> >>>>> 1) Our distribution already contains the manifest.jar and >>>>> equinox-manifest.jar: >>>>> * manifest.jar has the Main-Class set to the node launcher and >>>>> Class-Path >>>>> set to the required Tuscany modules and 3rd party jars >>>>> * equinox-manifest.jar has the Mani-Class set to the equinox node >>>>> launcher >>>>> and Class-Path set to the dependent jars for the launcher itself >>>>> without >>>>> pulling other Tuscany modules and 3rd party jars which are bundles >>>>> under >>>>> OSGi. We also have the configuration generated to list the bundles. It >>>>> can >>>>> be pointed using -Dosgi.configuration.area (system property). >>>>> >>>>> I suggest that our tuscany.bat to leverage that instead of using the >>>>> osgi.config and default.config which require manual maintenance and ** >>>>> classpath drags unnecessary jars. >>>>> >>>>> 2) Let's use -<option> instead of positional arguments. For example, >>>>> >>>>> tuscany -osgi contrib >>>>> >>>>> 3) We should allow the deployment composite to be used to launch the >>>>> node, >>>>> for example >>>>> >>>>> tuscany -composite <compositeURI> contrib1 contrib2 ... contribN >>>>> >>>>> The compositeURI can be a relative URI in one of the contribs or an >>>>> absolute >>>>> URI which points to an external composite file. >>>>> >>>>> 4) Do we prefer to have multiple commands for different purposes or one >>>>> command with different options? >>>>> >>>>> >>>>> Some of those sounds really good, just to explain, there are two things >>>>> that >>>>> led to it being as it is right now. Firstly lots of ML discussion about >>>>> runtimes, launching, and running samples where aspects of how this >>>>> should >>>>> work came up, without giving links to all the emails an OTTOMH summary >>>>> is - >>>>> to have a Tuscany persona, to remove the mystery about what happens, >>>>> to >>>>> make it simple, intuitive and consistent, and to enable simple sample >>>>> builds. The second reason its like this is to get something going >>>>> quickly >>>>> with minimum work as it wasn't obvious if eveyone agreed we wanted >>>>> something >>>>> like this. One other thing was to make the .bat/.sh scripts as simple >>>>> as >>>>> possible as they're hard to maintain. >>>>> >>>>> For (1) i'm nervous it makes it complicated and makes it hard to see >>>>> whats >>>>> going on. The current config file is simple and fairly intuitive so >>>>> there is >>>>> no mystery compared to digging around in a bat script to point to jars >>>>> somewhere else which you then have to unzip and look in the manifest. >>>>> >>>>> <rfeng>I have a different take here for the following reasons: >>>>> >>>>> a) MANIFEST.MF is defined by the jar spec and "Main-Class" and >>>>> "Class-Path" >>>>> are standard headers >>>>> b) The manifest.jar and equinox-manifest.jar have the accurate set of >>>>> classpath entries. And we also support the different configurations >>>>> based on >>>>> the distro, such as one for core, and one for web service. They are >>>>> automatically generated by Tuscany and no manual steps are required. >>>>> c) The OSGi launcher should not pull in other Tuscany modules and 3rd >>>>> party >>>>> jars which are OSGi bundles. Having them on the launcher classpath is >>>>> problematic. >>>>> d) Arguing about mystery, the launcher is already on the magical path >>>>> anyway. I'm trying to avoid intuitive directory scanning in >>>>> non-development >>>>> mode. >>>>> >>>>> >>>>> Well it doesn't seem as magical or mysterious as the alternative to me, >>>>> any >>>>> newbie could look at the bat scripts and config files and likely >>>>> understand >>>>> what was going on. IMVHO we seem to over engineer and complicate so >>>>> much in >>>>> Tuscany, to a actual user running tuscany.bat would it really make any >>>>> difference at all? What ever, how about we wait till all the >>>>> distribution, >>>>> feature, and sample running discussions have got a bit more finalized >>>>> so we >>>>> know for sure if we need something like this launcher at all and if so >>>>> exactly what it needs to do? >>>>> >>>>> For (c) could you give a bit more detail? We can probably fix it just >>>>> by >>>>> adding some more to the config file. >>>>> >>>>> ...ant >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Luciano Resende >>>> Apache Tuscany, Apache PhotArk >>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> >>>> http://lresende.blogspot.com/ >>>> >>> >>> > I switched calculator-rmi-sevice/buil.xml over to use this launcher and > specify a timeout. A handy tactical fix. You'll see in > itest/samples/build.xml that the rmi bit is commented out. The timeout seems > to work but after the node is stopped the node launcher doesn't terminate. I > expect we are holding some thread open somewhere. I don't think this has > anything to do with the addition of the timeout but I don't have time to > check it out just now. > > Simon > Hmm. This means that users trying to run the sample with the "ant run" target have the node shutdown after a few seconds and there is nothing they can do about it! That seems quite far from ideal. (and on a side note isn't the launcher timeout just duplicating function already available on the Ant tasks?) Having itests to test the samples is really good but it needs to be non-invasive, the primary purpose of the samples is to show users how to do things as clearly as possible, if we can't get the itests working without impacting the usability of the samples then i'd prefer we stay with the old manual testing of the samples. Fortunately I think there will be ways we can do the automated testing of this type of sample, perhaps using Ant timeouts, IO Redirectors, or even a our own custom Ant task if necessary. ...ant
