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

[Brian Stansberry]

On 1/5/11 9:14 AM, David M. Lloyd wrote:
> On 01/05/2011 08:54 AM, Brian Stansberry wrote:
>> On 1/5/11 8:17 AM, David M. Lloyd wrote:
>>>> 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.
>
> I'm not sure this is really necessary.  I'd think we'd have runtime
> operations available to query the actual values in use for these kinds
> of things; I think for regular model queries the user would want to read
> back the expressions only.
>

This is true. The client can decide how to handle this themselves. 
Simply returning PROPERTY_EXPRESSION from ModelNode.getType() is enough 
to tell the client that the value needs to be resolved; they can decide 
what to do with that information.

> Or maybe the read operation request parameters could contain a flag to
> resolve expressions?
>
> I suspect that we'd want to take active steps to prevent the user from
> resolving a node in the wrong place though.  Maybe an explicit
> .resolve() method which copies the current node with all values
> resolved?  That way the user won't be bitten by a doing .asString() and
> suddenly getting a different value than is on the server.

I see what you've done with that in the latest jboss-dmr. That seems 
fine. As long as we javadoc that resolve() is going to resolve using the 
system properties in the local VM, which are likely meaningless on the 
client, that covers it.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat