File: launchusage.xml

package info (click to toggle)
classworlds 1.0.1-1.1
  • links: PTS
  • area: contrib
  • in suites: etch, etch-m68k, sarge
  • size: 548 kB
  • ctags: 381
  • sloc: java: 3,211; xml: 1,103; makefile: 45
file content (170 lines) | stat: -rw-r--r-- 4,424 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
<?xml version="1.0"?>

<document>

  <properties>
    <title>App Launching</title>
    <author email="bob@eng.werken.com">bob mcwhirter</author>
  </properties>

  <body>

  <section name="Introduction">

    <subsection name="Purpose"> 

      <p>
      In order to reduce the number of classloading projects,
      <code>classworlds</code> replaces <code>forehead</code>
      for application launching.  
      </p>

      <p>
      The main problems to solve in application launching include
      locating all of application's JARs, configuring the initial
      classloaders, and invoking the <code>main</code> entry method.
      </p>

      <p>
      The launcher facilities of <code>classworlds</code> simplify
      the process of locating application jars.  A common idiom is
      to have a script which starts the JVM with only the 
      <code>classworlds.jar</code> in the classpath and a system
      property to specify the location of a launcher configuration.
      Additionally, typically a property specifying the installation
      location is passed on the command-line.
      </p>

<source><![CDATA[
$JAVA_HOME/bin/java \
    -classpath $APP_HOME/lib/classworlds-1.0.jar \
    -Dclassworlds.conf=$APP_HOME/etc/classworlds.conf \
    -Dapp.home=$APP_HOME \
    org.codehaus.classworlds.Launcher \
    $*
]]></source>

    </subsection>

  </section>

  <section name="Configuration">

    <subsection name="Entry Definition">

      <p>
      The entry-point class and realm must be specified
      using the <code>main is</code> directive before
      specifying realm definitions. 
      </p>

<source><![CDATA[
main is com.werken.projectz.Server from app
]]></source>

    </subsection>

    <subsection name="Realm Definitions">

      <p>
      At least one <code>classworlds</code> realm must be defined
      within the configuration file.  The syntax for starting a
      realm definition is <code>[realm.name]</code>.  All lines
      following the realm header are considered directives for 
      that realm.  The realm definition continues either until
      another realm is defined or until the end of the file is
      reached.  
      </p>

<source><![CDATA[
[realm.one]
    ...
    ...

[realm.two]
    ...
    ...

[realm.three]
    ...
    ...
]]></source>

      <p>
      Within a realm definition, two directives are available:
      <code>load</code> and <code>import</code>.  
      </p>

      <p>
      The <code>load</code>
      directive specifies a class source to be used for loading
      classes in the realm.  Any loaded source that ends with
      the <code>/</code> character is considered a directory
      hierarchy of classes and resources and all others are
      considered to be JAR files.  System properties may be
      referred to using <code>${propname}</code> notation.
      The <code>load</code> directive is equivelent to the
      <code>addConstituent(..)</code> method of <code>ClassRealm</code>.
      </p>

<source><![CDATA[
[app]
    load ${app.home}/lib/myapp.jar
    load ${app.home}/lib/xerces.jar
    load ${tools.jar}
]]></source>

      <p>
      The <code>import</code> directive specifies that certain
      packages should be imported and loaded by way of another
      realm.  The <code>import</code> directive is equivelent
      to the <code>importFrom(..)</code> method of
      <code>ClassRealm</code>.
      </p>

<source><![CDATA[
[app]
    ...
  
[subcomponent]
    import com.werken.projectz.Foo from [app]
    ...
]]></source>

    </subsection>

    <subsection name="Entry point methods">

      <p>
      <code>classworlds</code> can be used to invoke any existing
      application's <code>main()</code> method.  Using the standard
      entry point does not allow for gaining access to the 
      <code>ClassWorld</code> of the application, but not all 
      applications will need it at run-time.
      </p>

      <p>
      For those applications that do require the <code>ClassWorld</code>
      instance, an alternative entry-point method signature can be
      provide.  Simply add a <code>ClassWorld</code> parameter to 
      the standard <code>main</code> parameter list.
      </p>

<source><![CDATA[
public class MyApp
{
    public static void main(String[] args,
                            ClassWorld world)
    {
        ...     
    }
}
]]></source>

    </subsection>

  </section>

  </body>

</document>