[
https://issues.apache.org/jira/browse/TUSCANY-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder reassigned TUSCANY-2789:
----------------------------------
Assignee: ant elder
> 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
> Assignee: 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.
