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

[Brian Stansberry]

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?

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat