6:03 p.m.
On 05/26/2010 10:51 AM, Bela Ban wrote:
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
> 254.x.x.x
> - 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.[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.
>
> 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 there is a single place where such configuration is allowed (e.g. an
AS 7 domain configuration document) and all services that need to
consume the value must get it from the domain model, fine. But that
ain't how AS 6 works. And this discussion started with a request to get
something in M4, so that's what I'm talking about. :)
In AS 6, this kind of logic cannot be centralized in a single place.
Just in clustering alone, the AS deals with 4 separate projects that
each have their own configuration parsers.
> That would be too much work, since as soon as you allow it one
> configuration document you should allow it everywhere.
Yes, but again, if this is centralized, this should be simple. In
JGroups, processing of all IP addresses (IpAddress, InetAddress, or
lists thereof) is done in 1 place (via annotations).
> 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:
>
> -Djboss.bind.address.myfoosocket=PUBLIC
>
> 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.
IMO, GLOBAL, SITE_LOCAL, LOOPBACK etc are *IP addresses*, as good as the
dotted decimal notation (192.168.1.5) ! They are simply resolved at boot
time, versus statically.
If we allow for these keywords to be used with -b, then it would be
weird for users not to be able to use them in XML config files or as
system properties !
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
6:27 p.m.
New subject: Public IP address used by JBoss AS
Brian Stansberry wrote:
> All of this logic can be centralized (in JGroups it is in 1
place)
> and used everywhere.
>
If there is a single place where such configuration is allowed (e.g. an
AS 7 domain configuration document) and all services that need to
consume the value must get it from the domain model, fine. But that
ain't how AS 6 works. And this discussion started with a request to get
something in M4, so that's what I'm talking about. :)
And I was hoping you'd implement it by the time I arrive at work
tomorrow :-) ha ha
Actually, I don't care where JGroups gets its value, whether it is from
the XML config, system properties, default values etc. At the end of the
day, JGroups looks at all the fields (in all protocols) annotated with
@Property and intercepts setting of the value from a String.
I suppose something similar could be done in the AS: intercept setting
the java.lang.reflect.Field and try to come up with a meaningful
transformation of the Object for all fields of type InetAddress. E.g.
Object could be a String ("192.168.1.5", "http1.dyndns.org",
"GLOBAL"
etc) or an Object (e.g. InetAddress).
In AS 6, this kind of logic cannot be centralized in a single place.
Just in clustering alone, the AS deals with 4 separate projects that
each have their own configuration parsers.
That's why the logic to convert untyped values to typed (and meaningful
values) should be in an interceptor placed in front of fields we want to
convert (or sanity check)
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
6:58 p.m.
New subject: Public IP address used by JBoss AS
On 05/26/2010 11:27 AM, Bela Ban wrote:
Brian Stansberry wrote:
>> All of this logic can be centralized (in JGroups it is in 1 place)
>> and used everywhere.
>>
>
> If there is a single place where such configuration is allowed (e.g. an
> AS 7 domain configuration document) and all services that need to
> consume the value must get it from the domain model, fine. But that
> ain't how AS 6 works. And this discussion started with a request to get
> something in M4, so that's what I'm talking about. :)
And I was hoping you'd implement it by the time I arrive at work
tomorrow :-) ha ha
LOL. If I didn't feel compelled to discuss first, I'd have probably
hacked it into org.jboss.Main this AM. Oh well.
Actually, I don't care where JGroups gets its value, whether it
is from
the XML config, system properties, default values etc. At the end of the
day, JGroups looks at all the fields (in all protocols) annotated with
@Property and intercepts setting of the value from a String.
I suppose something similar could be done in the AS: intercept setting
the java.lang.reflect.Field and try to come up with a meaningful
transformation of the Object for all fields of type InetAddress. E.g.
Object could be a String ("192.168.1.5", "http1.dyndns.org",
"GLOBAL"
etc) or an Object (e.g. InetAddress).
That's something to keep in mind for the domain model. There we are
dealing with a known, understood object model, where such logic could be
applied.
What you do with @Property works because you fully understand the object
model you are working with and you control the instantiation and
configuration of the objects. That's not the case in general with a lot
of things in AS 6. You also quite carefully specify which fields are
@Property and if needed how to do transformations. There's no confusion
as to whether a field of type String really represents an InetAddress.
> In AS 6, this kind of logic cannot be centralized in a single
place.
> Just in clustering alone, the AS deals with 4 separate projects that
> each have their own configuration parsers.
That's why the logic to convert untyped values to typed (and meaningful
values) should be in an interceptor placed in front of fields we want to
convert (or sanity check)
The 4 different projects have their own logic for parsing configuration
into an object model, all with a tendency to hide that logic as an
internal detail. So adding such interceptors is no small matter.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5092
days inactive
5092
days old
jboss-development@lists.jboss.org
2 comments
2 participants
participants (2)
-
Bela Ban -
Brian Stansberry