[jboss-as7-dev] Expressions (Detyped API document feedback)

[David M. Lloyd]

On 01/05/2011 08:10 AM, Brian Stansberry wrote:
> On 1/4/11 11:02 AM, David M. Lloyd wrote:
>>
>> MetaValues
>>
>> I agree with some of these types but not others:
>>
>> * SimpleValue
>>        + String - yes
>>        + primitives - some; maybe just boolean/int/long/float/double but
>> not byte/short/char for example
>>        + Date - no, let's use long for now, and revisit once JSR-310 is
>> done.  Date is basically worthless.
>>        + BigDecimal/BigInteger - yes
>> * CollectionValue/ArrayValue - No, I'd rather see byte[] added to the
>> above list and otherwise have a list value type, each element of which
>> can be whatever type
>> * MapValue - No, we don't need any map key type other than strings
>> * CompositeValue - too much work, why not just use a simple map of
>> Strings to values?  By making the type dependent on the key it's
>> basically impossible to use without metatype info
>> * TableMetaValue - too complex
>>
>> I'd rather do something more dynamic where you can start with a node and
>> just build up whatever you want from it:
>>
>> node = new ModelNode();
>> node.get("operation").set("change-bind-port"); // string
>> node.get("address").add("base, "domain"); // a list
>> node.get("address").add("profile", "web");
>> node.get("address").add("subsystem", "web");
>> node.get("address").add("connector", "ssl");
>> node.get("bind-port").set(8433); // int
>> result = connection.execute(node); // goes over remoting
>> System.out.println("Result is: " + result);
>> // nicely formatted, JSON-style (but with more possible types)
>>
>> I wipped up a demo of this style of API at:
>> https://github.com/dmlloyd/jboss-dmr
>>
>> Notice there's only one public class and one type enum.  (The Validation
>> class isn't anything, just an experiment.)
>>
>
> Something I want to work through with this is how is how to handle
> values that are really expressions or variable references (e.g.
> ${pool.size:10}) that should be resolved on the server.
>
> Using something like the old jboss-meta library that has different value
> types (SimpleValue, CollectionValue, CompositeValue etc), it's fairly
> straightforward to handle these. We could add a new value type
> ExpressionValue (or modify SimpleValue) and have it expose a few extra
> properties:
>
> String getExpression()
> String getDefaultValue()
> boolean isResolved()
>
> plus the standard getValue()
>
> When a user is reading the domain or host level model, isResolved()
> would return false. If the user is reading a server level model, it
> would return true, and getValue() would return the resolved value. But
> the underlying ${pool.size:10} would still be available, helping users
> to understand where the resolved value came from.
>
> With the simpler type system David proposes, this kind of thing isn't so
> easily doable. So, a couple questions to discuss:
>
> 1) The only place where something like ExpressionValue adds anything is
> when reading a server level model, where the resolved value is available
> *and* the unresolved value is available. Is there significant benefit in
> providing the unresolved value?
>
> 2) If there is significant benefit, how can we model this using the
> simpler type system?

Easy - I can add a PROPERTY_EXPRESSION type which attempts to resolve 
the expression when you call asString()/asInt()/etc. (toString() would 
return the expression).

Or, I can add asResolved*() which does resolution instead, with 
asString() returning the expression.

-- 
- DML