On 05/26/2010 09:52 AM, Andrew Lee Rubinger wrote:
Comments inline.
On 05/26/2010 09:03 AM, Brian Stansberry wrote:
<snip/>
>>
>> My current take on this is if we did it for AS 6 we'd implement it in
>> the org.jboss.Main class.[1] Basically we'd alter the command line
>> processing for -b, -Djboss.bind.address and -Djgroups.bind_addr to
>> detect the above aliases and replace with the appropriate value.
Main should really be pared down as slim as possible; putting this logic
there means it'll be available only in AS standalone.
Hehe, I had a feeling you'd say that!
Inside of jboss-boostrap we have the notion of "configuration
initialization". This is commonly-used for things like determining the
true bindAddress given an env variable, sysprop, object model. There's
an order of preference used in resolution.
Similarly looks like we just need to resolve these new "placeholders" to
appropriate true values. How exactly does this process work (ie, what's
the logic to know PUBLIC is x.x.x.x, what context do we need to do this)?
Bela implemented this for JGroups (JGRP-1204). Bela if this is
encapsulated in a couple classes, can you provide ALR some links? Best
via
http://javagroups.cvs.sourceforge.net/viewvc/javagroups/JGroups/ as
I doubt he wants to check out JGroups from cvs.
At fist glance looks like [1] could be the place for this.
And yes, object model should be the configuration API as much as
possible looking forward. The system property stuff is maintained for
back-compat's sake, and jboss-bootstrap-impl-as keeps these in sync.
S,
ALR
[1]
http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-as/s...
@ initialize()
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat