[wildfly-dev] Validating operation parameters

[Emmanuel Hugonnet]

Comments inline

Le 10/08/2015 19:14, Brian Stansberry a écrit :
> Please search for uses of the ParameterCorrector interface. Its function 
> is to allow server side handlers to adjust things.
> 
> This should not be part of WFCORE-74. It's a separate, more far reaching 
> task.

 Agreed, the CLI client side validation was more a POC on how to use the 'new' arbitrary descriptor.
> 
> In general I don't think this kind of client side validation is worth 
> the loss of flexibility. We have tab completion to help suggest correct 
> values.
> 
> Min/max validation is least likely to introduce problems.
Yes,that's why I didn't go further :D

> 
> Just dreaming, I can imagine an enum value being dropped from the list 
> of "legal" values, but the OSH still accepts/translates the old value to 
> provide compatibility for old scripts. That's somewhat broken and is a 
> bit of a corner case, but it's another example of how the server can be 
> "forgiving."
> 
> What sort of path validation did you have in mind? The remote client 
> cannot know what filesystems are in use in all possible locations 
> affected by an op, so I don't see how it can validate.

Currently it doesn't aim to validate a path but the CLI now use the FilenameTabCompleter so you can use tab to complete the attribute (using
a local to the cli path).
<brainstorming mode>
But for URL we could validate JDBC urls for example, or check that a web URL is reachable or at least is correct, or use SSL...
This also could be useful for JNDI names in completion as well as in validation : at least some basic format validation.
</brainstorming mode>

Emmanuel

> 
> On 8/10/15 11:53 AM, Emmanuel Hugonnet wrote:
>> Hi,
>> I'm currently working on adding more metadata on resource attributes and operation parameters or replies [1].
>> As an example I added the fact that an attribute of type STRING is in fact a filesystem path or an URL [2].
>> To show how this kind of metadata could be helpful I have updated the CLI so that it uses the filesystem path completer and to try to
>> validate the operation parameters :
>> for example checking that an URL has a correct format before executing an operation.
>> This led me to provide more validation : checking that an integer is in the valid range, etc.
>> Brian rightfully pointed out that in some case we are defining than an operation parameter is defined a certain type while the handler
>> supports multiple types :
>>   for example the DeploymentAddhandler.CONTENT_ALL should get a LIST of only one object  but supports getting the object directly.
>> So I'm wondering about adding support for range or type validation for 'complex' types as it may break existing valid (as in accepted even
>> if wrong) operations.
>> What do you think ? Do you see other edge cases like this one ?
>> Emmanuel
>>
>> 1: https://issues.jboss.org/browse/WFCORE-74
>> 2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150810/3e6fd586/attachment-0001.bin