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

[Brian Stansberry]

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