On 05/26/2010 09:03 AM, Brian Stansberry wrote:
OK, this time I'll actually send it to the list...
On 05/26/2010 07:38 AM, Brian Stansberry wrote:
> Putting this on jboss-dev, as my guess is 3/4 of the work is discussing
> a bit. Particularly interested in hearing from Mr. Boot, ALR.
> What we're talking about is https://jira.jboss.org/browse/JBAS-8001
> which is a proposal to allow some standard aliases for IP addresses that
> the AS would resolve to something meaningful on the local machine. The
> purpose is to make it easier to use the AS in a cloud environment where
> the user can't know addresses in advance. Proposed aliases are:
> - GLOBAL: picks a global (public) address
> - SITE_LOCAL: an address starting with 192.168.x.x or 10.0.x.x
> - LINK_LOCAL: a link local address, ie. starting with 169.x.x.x or
> - NON_LOOPBACK: picks any non-loopback address
> - LOOPBACK: picks a loopback address
> My current take on this is if we did it for AS 6 we'd implement it in
> the org.jboss.Main class. 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.
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)?
At fist glance looks like  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.
> IMO we would *not* allow these values as a general configuration option,
> e.g. in a -jboss-beans.xml:
> <!-- Not supported -->
> <property name="bindAddress">PUBLIC</property>
> That would be too much work, since as soon as you allow it one
> configuration document you should allow it everywhere.
> The weakness of only using it via Main's command line processing is if
> people only want to use, for example, PUBLIC, in one spot, not as a
> global value like -b. If we want to help with that, perhaps we could use
> a system property namespace, and have Main check for properties in that
> namespace and resolve them. For example:
> My instinct though is to *not* support that. First, to me there is no
> clear use case. Second, in AS 7 I'm pretty sure we are going to want to
> move away from system properties as a core way of configuring the AS, so
> let's not add new system property-based features in 6.
> On 05/26/2010 07:07 AM, Bela Ban wrote:
>> In my mod-cluster demo, every JBoss instance needs to set the IP address
>> used by its AJP connector to a *public* IP address, regardless what
>> jboss.bind.address is set to. The reason is that the httpd's mod-cluster
>> will connect back to the JBoss instance via AJP, and if httpd runs in a
>> different cloud, then a randomly chosen IP address may or may not work.
>> For example, it wouldn't work if JBoss picked a site-local (e.g.
>> 192.168.x.x.x) IP address...
>> However, since I don't know the public IP addresses available on the
>> NICs provided by a virtualized instance in the cloud to a JBoss
>> instance, I would have to come up with complicated scripts which find
>> out the public IP address(es) and set -Djboss.bind.address to it.
>> On top of that, I don't really need to set jboss.bind.address, I really
>> only want to set the IP address from the AJP connector (in server.xml).
>> So I was wondering whether (when ! :-)) something like  will be
>> available in JBoss AS: I could then simply set
>> -Djboss.bind.address=PUBLIC and JBoss AS would pick any suitable public
>> IP address on any interface that's not down...
>> I know there's a JIRA around for this somewhere, and I was wondering if
>> there's a chance to get this into M4, so I don't have to write crappy
>> scripts to set jboss.bind.address... :-)
>>  https://jira.jboss.org/browse/JGRP-1204
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat