-
Notifications
You must be signed in to change notification settings - Fork 115
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
How must converters be indexed? #740
Comments
I don't think that's explicitly specified. However: Certain use cases do use subclasses implicitly, e.g. CDI injection. This works:
This will use the String-Converter, because there must be a CDI bean (necessarily a producer method in this case) of type However, the way this is implemented (and the only this can be implemented) is that all injection points are scanned at startup (or even at built-time) and a synthetic bean of the corresponding type is registered. Of course, this will not register all possible subtypes. The CharSequence examples only works, because the I have not tried it, but I imagine, this could be a mess if two types in a class hierarchy both qualify for automatic converters. Injection points for the superclass will then resolve to two |
Suppose I call
Config.getOptionalValue("foo", CharSequence.class)
.Suppose there is not a
Converter
indexed underCharSequence.class
directly.Suppose there is a
Converter
registered underString.class
(there must be, if I read the specification properly, becauseString
has avalueOf()
method).Must the
Converter<String>
be used in this case by aConfig
implementation? If so, could you provide the specification reference, please?Or: Must it not be used? If not, could you provide the specification reference, please? Will an
IllegalArgumentException
be thrown (I presume that is the exception that is thrown if conversion cannot happen for any reason)?May it be used? (If this area is undefined, then what, honestly asking, is the purpose of this particular method?)
(The javadoc for
getOptionalValue()
also does not require that converters be used at all, i.e. it would be legal for aConfig
implementation to do whatever it wants in this method to perform conversion. But that's a separate issue that was never fully resolved.)The text was updated successfully, but these errors were encountered: