Re: [jboss-dev] Public IP address used by JBoss AS

On 05/26/2010 12:53 PM, Andrew Lee Rubinger wrote: > > > On 05/26/2010 01:45 PM, Brian Stansberry wrote: >> 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. > > Is that true? > > Why not allow input of bindAddress=="PUBLIC", which may resolve to > 201.23.2.100 within the same property? Do we need to hang on to the > inputs or just resolve them to a real jboss.bind.address? So then it'd > be: > > <property name="bindAddress"><inject bean="JBossASConfiguration" > property="bindAddress"/></property> > > ...which we already have. > That leaves you with only one address. It doesn't support the equivalent of the following for some service or combination of services: <property name="externalAddress">PUBLIC</property> <property name="intraClusterAddress">SITE_LOCAL</property> The need for that kind of flexibility is the argument for being able to resolve PUBLIC et al at any injection point.

> >> >> 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? >> >