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
