-
Notifications
You must be signed in to change notification settings - Fork 395
Converter not called as expected / difference in call by name vs position #694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
branch/3.0.x
Issue for a branch
branch/3.1.x
Issue for a branch
for/backport
For backporting
type/bug
Is a bug report
Milestone
Comments
Thanks for the detailed explanation and yes I see the issues you outlined. I'll dig this a bit deeper before I put more comments here. |
This was referenced Apr 1, 2023
Closed
jvalkeal
added a commit
to jvalkeal/spring-shell
that referenced
this issue
Apr 1, 2023
- In `CommandRegistration` add `ResolvableType` for `OptionSpec` giving more spesific handling of a type. - In `CommandParser` handle source and target types so that we have generics with `List`, `Set` and arrays working better. - In `HandlerMethodArgumentResolver` add better handling for `ConversionService` for generic types. - In `StandardMethodTargetRegistrar` add better types via `ResolvableType` now that `CommandRegistration` support it. - In `OptionConversionCommands` remove converter from `String` to `Set` as now things should work as is if generic in a `Set` has a converter. - Fixes spring-projects#694
jvalkeal
added a commit
to jvalkeal/spring-shell
that referenced
this issue
Apr 2, 2023
- In `CommandRegistration` add `ResolvableType` for `OptionSpec` giving more spesific handling of a type. - In `CommandParser` handle source and target types so that we have generics with `List`, `Set` and arrays working better. - In `HandlerMethodArgumentResolver` add better handling for `ConversionService` for generic types. - In `StandardMethodTargetRegistrar` add better types via `ResolvableType` now that `CommandRegistration` support it. - In `OptionConversionCommands` remove converter from `String` to `Set` as now things should work as is if generic in a `Set` has a converter. - Fixes spring-projects#694
jvalkeal
added a commit
to jvalkeal/spring-shell
that referenced
this issue
Apr 2, 2023
- In `CommandRegistration` add `ResolvableType` for `OptionSpec` giving more spesific handling of a type. - In `CommandParser` handle source and target types so that we have generics with `List`, `Set` and arrays working better. - In `HandlerMethodArgumentResolver` add better handling for `ConversionService` for generic types. - In `StandardMethodTargetRegistrar` add better types via `ResolvableType` now that `CommandRegistration` support it. - In `OptionConversionCommands` remove converter from `String` to `Set` as now things should work as is if generic in a `Set` has a converter. - Backport spring-projects#694 - Fixes spring-projects#699
jvalkeal
added a commit
to jvalkeal/spring-shell
that referenced
this issue
Apr 5, 2023
- In `CommandRegistration` add `ResolvableType` for `OptionSpec` giving more spesific handling of a type. - In `CommandParser` handle source and target types so that we have generics with `List`, `Set` and arrays working better. - In `HandlerMethodArgumentResolver` add better handling for `ConversionService` for generic types. - In `StandardMethodTargetRegistrar` add better types via `ResolvableType` now that `CommandRegistration` support it. - In `OptionConversionCommands` remove converter from `String` to `Set` as now things should work as is if generic in a `Set` has a converter. - Backport spring-projects#694 spring-projects#699 - Fixes spring-projects#700
Hello, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
branch/3.0.x
Issue for a branch
branch/3.1.x
Issue for a branch
for/backport
For backporting
type/bug
Is a bug report
Uh oh!
There was an error while loading. Please reload this page.
Hello,
Up to recently we have been using Spring Shell 2.1.2 but after trying to upgrade to later version(s) we have noticed a change in behavior how Converters are called. Also, there seems to be a difference if the command invocation uses named parameters or positional parameters.
Given the below @ShellMetods and a custom Converter (String -> MyType) the results will be as in the table below with different versions of Spring Shell:
And
The following invocations are used
The expected behavior would be that the Converter is invoked for each value 'a', 'b' and the result being collected into the correct collection type.
The result is as below.
String
("a,b")List<String>
)The text was updated successfully, but these errors were encountered: