Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Create a new Tuscany launcher module that separates all the functions related to setting up the runtime environment into a standalone module. This will give Tuscany a standard and consistent way to start a runtime - a "persona", and helps remove the mystery around what gets setup by having it driven by text based config files instead of hard coded within Java classes. See ML discussion: http://apache.markmail.org/message/i563kc4o6ib5lq4c, some more description from that thread is:
Separate out the "launcher" functionality to its own module which focuses purely on setting up a classpath and calling some main class, with no code to do anything like calling Tuscany specific Node APIs etc, and have that launcher configured by external config files which define the classpath and main class to call. Then provide several config files for the various environments and runtimes we want to support. The launcher jar and config files would go in separate "bin" folder in the distribution (or maybe the top level folder), and like the old tuscany manifest jar the launcher jar name wouldn't include a version number to make it simple and consistent across releases.
So a distribution would look something like:
tuscany-2.0/
bin/launcher.jar
bin/default.config
bin/osgi.config
bin/manager.config
bin/myCustomConfigThatUsesJMSandJDK6.config
lib/...
samples/...
To run something like the calculator sample with the standalone runtime you'd do: "java -jar bin/launcher.jar sample.calculator.jar" which would use the default.config and to use one of the other config files you'd set a property or use an additional parameter,eg: "java -jar bin/launcher.jar osgi sample.calculator.jar".
The config files could be simple Java properties files defining the jars and folders to add to the classpath and the class with the main method to run, and support some simple wildcards, eg:
mainClass=org.apache.tuscany.sca.node.NodeMain
classpath1=../lib/core/*
classpath2=../lib/jetty/*
classpath3=../lib/webservices/*
Could even be a bit more fancy and support some simple conditionals in the classpath properties to enable only setting a classpath for specific JDK levels etc.
The advantages of this approach is that its parameterized and its no longer mysterious what the launcher is doing. It also makes things very flexible and easy to customize the runtime environment without changing any code, and it goes along with the "modularity story" by not munging the launcher and tuscany node startup code into one module.
What we're trying to do is common for many other projects, I've looked at a whole bunch to see what they do, there are several common approaches from using bat scripts, proprietary launchers to 3rd party launcher projects etc, this particular approach seems best to me, its based on the approach used by Jetty: http://docs.codehaus.org/display/JETTY/A+look+at+the+start.jar+mechanism
Attachments
Issue Links
- is depended upon by
-
TUSCANY-2810 Launching the tuscany runtime
-
- Closed
-