Le 10/08/2015 19:14, Brian Stansberry a écrit :
Please search for uses of the ParameterCorrector interface. Its
is to allow server side handlers to adjust things.
This should not be part of WFCORE-74. It's a separate, more far reaching
Agreed, the CLI client side validation was more a POC on how to use the 'new'
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
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
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).
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.
On 8/10/15 11:53 AM, Emmanuel Hugonnet wrote:
> I'm currently working on adding more metadata on resource attributes and
operation parameters or replies .
> As an example I added the fact that an attribute of type STRING is in fact a
filesystem path or an URL .
> 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
> 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 ?
> 1: https://issues.jboss.org/browse/WFCORE-74
> 2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74
> wildfly-dev mailing list