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

[Brian Stansberry]

On 1/5/11 8:17 AM, David M. Lloyd wrote:
> 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?
>>

Answering my own question: the benefit is greater in standalone mode. 
Being able to see both the resolved and unresolved value is most 
significant when you want to modify the value. Say the configured value 
is really ${pool.size:10} but the resolved value is 15: if the user 
wants to change it to a constant 20, they need to know they are 
replacing a variable with a constant.

In domain mode, the modifiable view is at the domain level, and the 
unresolved value is visible. If the unresolved value is isn't visible at 
the server level, it's not so bad as the user can't directly change the 
configuration there anyway.

In standalone mode, there isn't that separation.

>> 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).
>

This would need to be done on the server side and the calculated result 
shipped to the client.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat