On Tue, 2010-05-04 at 22:18 +0200, Bela Ban wrote:
>> So when this is done, what will the configuration steps be
>> JBoss AS side) ?
>> 1. Add a jvmRoute to server.xml [optional, as jvmRoute is generated
>> if absent]
> The default JvmRouteFactory allows system property override as well,
> via -Djboss.mod_cluster.jvmRoute
I assume you're referring to the *factory*, so would the property be
something like -Djboss.mod_cluster.jvmRoute.factory=CLASSNAME ?
No - the jvm route itself.
Implementation-wise, the default JvmRouteFactory is:
new SystemPropertyJvmRouteFactory(new UUIDJvmRouteFactory(),
So, it returns the given system property, if defined; or if not, a UUID.
If you want to override the factory itself, you would modify the
jvmRouteFactory property of the ModClusterConfig bean within
<bean name="ModClusterConfig" class="...">
<!-- Generates jvm route as: bind-address:port:engine-name -->
>> 2. mod-cluster.sar:
>> 1. Set the proxy list (jboss.mod_cluster.proxyList) [optional
>> if IP multicasting works, as advertise is enabled by default]
> Advertise is not enabled by default - in order to minimize jboss's
> default port footprint. Advertise can be enabled via a system property.
> So, in summary, the servers just need to be started with either:
OK. In order to create virtual images for GoGrid, EC2 and Rackspace, I
want to avoid using system properties as much as possible. So jvmRoutes
need to be either hard coded, or my startup script (/etc/init.d/jboss)
will have to provide unique values for them, e.g. via uuidgen.
You don't need to use a system property to get unique auto-generated jvm
routes by default. See above.
In general, system properties are only used for convenience, i.e. to
allow the user to override commonly used configuration properties via