Create a new Tuscany "launcher" module
--------------------------------------
Key: TUSCANY-2789
URL: https://issues.apache.org/jira/browse/TUSCANY-2789
Project: Tuscany
Issue Type: New Feature
Reporter: ant elder
Fix For: Java-SCA-2.0-M1
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
