On 05/26/2010 11:43 AM, Andrew Lee Rubinger wrote:
On 05/26/2010 12:09 PM, Bela Ban wrote:
> Brian Stansberry wrote:
>> 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>
>
> -100 IMO: a user may want to define an address based on some criteria,
> so the above makes perfect sense ! I can even envisage that we support
> something like this later:
>
> <property
name="bindAddress">192.168.*,274.2.*,SITE_LOCAL</property>,
>
> which means that we should try to pick a site local address starting
> with 192.168, if not found a global IP address starting with 274.*, and
> if still not found, go and grab any site local address.
>
> All of this logic can be centralized (in JGroups it is in 1 place) and
> used everywhere.
If we put the resolution logic inside of jboss-bootstrap, any MC
component can @Inject or<inject> the JBossASConfiguration and do
getBindAddress() (even if the input was something like "PUBLIC"). The
configuration initialization phase would resolve before the server comes up.
If the goal is fine grained configuring what type of interface an
interface uses, then the closest mapping to:
<property name="bindAddress">PUBLIC</property>
is
<property name="bindAddress"><inject
bean="JBossASConfiguration"
property="publicAddress"/></property>
So that implies new properties in JBossASConfiguration.
Since this is really an API discussion, I'd still like to hear more
about what the real world use cases are. I get the one where a server
listens on interface X for external requests and uses interface Y for
internal to the cluster traffic. I can dream up others. What other ones
are actually used?
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat