Re: [jboss-dev] 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