6:53 p.m.
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
7:14 p.m.
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.
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.
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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:02 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
3175
days inactive
3175
days old
2 comments
2 participants
participants (2)
-
Brian Stansberry -
Emmanuel Hugonnet