Sorry I was wrong. When Guice is choosing the converter, both converters
exist in a list, and the latter one in the list wins. Overlapping is always
detected and recorded by Guice. It happens that in one of my example which
appeared to work, the injection/binding happens with just-in-time, which
drops errors. But fundamentally there is no effective way to "override" the
internal injector as there seems no guarantee on the order of the converter
list. So any attempt to hack using just-in-time seems not a good idea.
On Friday, April 26, 2013 12:28:09 PM UTC-7, Kevin Zhao wrote:
>
> Hi Guice folks,
>
> The project I am working on has a weird notation for configuration
> properties that 1 stands for True and anything else for False.
> Binder.convertToTypes() seems quite convenient for me to declare my own
> String -> Boolean conversion. What I am not sure is this seems to coexist
> with the internal primitive bindings for String -> Boolean. Therefore
> although my conversion seems to effectively override the internal
> conversion, I would like to check if it is indeed OK so that it is
> reasonably less likely to break in the future releases of Guice. Thanks!
>
>
> binder().convertToTypes(Matchers.only(TypeLiteral.get(Boolean.class)), new
> TypeConverter() {
> @Override
> public Object convert(String value, TypeLiteral<?> toType) {
> return Boolean.parseBoolean(value) || value.equals("1");
> }
> });
>
> BTW, I would be doing this in private modules to be less pervasive.
>
> Best,
> -Kevin
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
