boolean default value

[Postremus]

I have a query param in my resource of type boolean, primitive. If the client does not specify it, it is set to false (since default of primitive boolean). Can this please also be reflected in openapi?

    @QueryParam("deleted")
    public boolean deleted;

Instead of:

- 
        name: deleted
        in: query
        schema:
          type: boolean

I want:

- in: query
        schema:
          type: boolean
          default: false

Is this something you would add as default in this project, or should I annotate all my booleans with @DefaultValue("false")?

[MikeEdgar]

I see your point, but it would be a pretty significant change to make the scanner automatically behave this way. It could certainly be a configuration option, but I wonder if it would be the type of thing that applies to any primitive, and also properties of objects that are primitive.

I don't quite remember - without a @DefaultValue, can JAX-RS parameters be completely omitted (defaulting to the primitive default) or is there something enforcing query parameters are present?

[Postremus]

I don't quite remember - without a @DefaultValue, can JAX-RS parameters be completely omitted (defaulting to the primitive default) or is there something enforcing query parameters are present?

Yes. If I for example request my resource like <host>/accounts, then the deleted Query Param has a value of false. Even without the DefaultValue annotation. My resource method is called.

The javadoc of DefaultValue also states:

 * If this annotation is not used and the corresponding meta-data is not present in the request, the value will be an
 * empty collection for {@code List}, {@code Set} or {@code SortedSet}, {@code null} for other object types, and the
 * Java-defined default for primitive types.

[MikeEdgar]

I think a nice solution for this would be to use those JAX-RS defaults (those that @DefaultValue lists when the annotation is missing) for non-required parameters. Using them for parameters marked as required, particularly @PathParams seems like it could be misleading.

[Azquelt]

I think this is mostly right.

It's worth noting that @DefaultValue can provide a value that it wouldn't be valid for a user to send.

I also note that @DefaultValue is valid on path parameters. I think this could be used if you injected the path parameter in a field, or if the resource method can be reached by multiple paths (using sub-resource locators) and not all paths include the parameter.

[MikeEdgar]

It's worth noting that @DefaultValue can provide a value that it wouldn't be valid for a user to send.

This is a good point. A solution for this issue could attempt to determine whether the default derived in the absence of @DefaultValue would violate some other constraint. This could certainly become complicated in the case of referenced or composite schemas, so it would only be a best-effort type of thing.

I also note that @DefaultValue is valid on path parameters. I think this could be used if you injected the path parameter in a field, or if the resource method can be reached by multiple paths (using sub-resource locators) and not all paths include the parameter.

Also true, but do we need to support path parameters (or any other required parameters) with this change? It seems fair to ignore required ones here and for those cases users may still use their own @DefaultValue or the @Schema to give a default if they choose.

[Azquelt]

It's worth noting that @DefaultValue can provide a value that it wouldn't be valid for a user to send.

This is a good point. A solution for this issue could attempt to determine whether the default derived in the absence of @DefaultValue would violate some other constraint. This could certainly become complicated in the case of referenced or composite schemas, so it would only be a best-effort type of thing.

This could be done, though it's not simple and we don't currently have any schema validation implementation to use as a base.

FWIW, the situation I was thinking of here was where you're injecting an optional integer parameter and 0 is a valid value. You need to force the default to an invalid value (e.g. -1 or MIN_INT) so that you can distinguish between the user providing 0 or the user not providing a value.

I've also realised I misread the request. We already set default based on @DefaultValue, and we're requesting we do the same for parameters without @DefaultValue. I suspect this is actually more likely to be ok, except in the case where a property is required and application code is checking that it's not set to a default value. In that case, suggesting the invalid default value in the UI would be unhelpful.

[Azquelt]

One further concern is that I'm not sure we have a way to unset the default value, if the user didn't want it included in the OpenAPI.