Dynamic binding inference

['Mariano Gonzalez' via google-guice]

Hello,

I have a case in which a portion of the binding are dynamically provided
through a properties file with the following format:

exampleService=ExampleServiceImpl
fooService=FooServiceImpl


Unlike Guice's approach, the key is not a type but an actual Name. For now,
I'm just binding those concrete types to themselves, like
*bind(FooServiceImpl.class).to(bindFooServiceImpl.class)*

Of course this approach doesn't work because then the following injection
would fail:

public class Foo {


@Inject
private FooService fooService;


}

There's no default way in which Guice would figure out that FooService can
actually be served by FooServiceImpl. The alternative that I have thought
about so far is to introspect those types and generate bindings for each
superclass and implemented interface.

I was wondering is there's a less "brute force" approach.

Thanks

[Stephan Classen]

You could have a look at multi binders.
https://github.com/google/guice/wiki/Multibindings

Then bind all possible implementations of an interface and use the value
from the properties to select the one out of the set.

Post by 'Mariano Gonzalez' via google-guice
Hello,
I have a case in which a portion of the binding are dynamically
|
exampleService=ExampleServiceImpl
fooService=FooServiceImpl
|
Unlike Guice's approach, the key is not a type but an actual Name. For
now, I'm just binding those concrete types to themselves, like
/bind(FooServiceImpl.class).to(bindFooServiceImpl.class)/
Of course this approach doesn't work because then the following
|
publicclassFoo{
@Inject
privateFooServicefooService;
}
|
There's no default way in which Guice would figure out that FooService
can actually be served by FooServiceImpl. The alternative that I have
thought about so far is to introspect those types and generate
bindings for each superclass and implemented interface.
I was wondering is there's a less "brute force" approach.
Thanks
--
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
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

['Mariano Gonzalez' via google-guice]

Thank you.

Yes I looked at Multibinders but this still requires the brute force
approach. Each of my plugins can register any random object, I don't know
the universe of interfaces before hand. I was more looking in the direction
of somehow tapping into how the bindings are processed so that when Guice
realises that it cannot serve @Inject FooService I can catch that and
calculate that binding on demand?

Is this or something like that possible?

Thanks

Post by Stephan Classen
You could have a look at multi binders.
https://github.com/google/guice/wiki/Multibindings
Then bind all possible implementations of an interface and use the value
from the properties to select the one out of the set.
Hello,
I have a case in which a portion of the binding are dynamically provided
exampleService=ExampleServiceImpl
fooService=FooServiceImpl
Unlike Guice's approach, the key is not a type but an actual Name. For
now, I'm just binding those concrete types to themselves, like
*bind(FooServiceImpl.class).to(bindFooServiceImpl.class)*
Of course this approach doesn't work because then the following injection
public class Foo {
@Inject
private FooService fooService;
}
There's no default way in which Guice would figure out that FooService can
actually be served by FooServiceImpl. The alternative that I have thought
about so far is to introspect those types and generate bindings for each
superclass and implemented interface.
I was wondering is there's a less "brute force" approach.
Thanks
--
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
<javascript:>.
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Stephan Classen]

I don't think this would be a good approach. And I am not even sure if
guice would allow it.
I would rather propose that every plugin comes with a Module which is
then passed to the injector creation method.
This way every plugin can bind whatever it needs.
If multiple plugins try to bind the same thing you could always
encapsulate a plugin in a private module and only expose a limited set
of bindings.

If I miss the point here then maybe try to explain why you are passing
bindings in properties files...

Post by 'Mariano Gonzalez' via google-guice
Thank you.
Yes I looked at Multibinders but this still requires the brute force
approach. Each of my plugins can register any random object, I don't
know the universe of interfaces before hand. I was more looking in the
direction of somehow tapping into how the bindings are processed  so
catch that and calculate that binding on demand?
Is this or something like that possible?
Thanks
You could have a look at multi binders.
https://github.com/google/guice/wiki/Multibindings
<https://github.com/google/guice/wiki/Multibindings>
Then bind all possible implementations of an interface and use the
value from the properties to select the one out of the set.

Post by 'Mariano Gonzalez' via google-guice
Hello,
I have a case in which a portion of the binding are dynamically
|
exampleService=ExampleServiceImpl
fooService=FooServiceImpl
|
Unlike Guice's approach, the key is not a type but an actual
Name. For now, I'm just binding those concrete types to
themselves, like
/bind(FooServiceImpl.class).to(bindFooServiceImpl.class)/
Of course this approach doesn't work because then the following
|
publicclassFoo{
@Inject
privateFooServicefooService;
}
|
There's no default way in which Guice would figure out that
FooService can actually be served by FooServiceImpl. The
alternative that I have thought about so far is to introspect
those types and generate bindings for each superclass and
implemented interface.
I was wondering is there's a less "brute force" approach.
Thanks
--
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,
<javascript:>.
Visit this group at https://groups.google.com/group/google-guice
<https://groups.google.com/group/google-guice>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.

--
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
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

['Mariano Gonzalez' via google-guice]

The reason for binding as properties is basically backwards compatibility.
This is a legacy system originally built with spring. I'm trying to move to
guice because spring is way too heavy and takes a long time to start, but
all of this works out of the box.

Unfortunately, having each plugin ship with a module is not an option in
this case, which is why I'm looking for a way to leverage guice goodies
while while keeping spring's behavior.

Thanks

Post by Stephan Classen
I don't think this would be a good approach. And I am not even sure if
guice would allow it.
I would rather propose that every plugin comes with a Module which is then
passed to the injector creation method.
This way every plugin can bind whatever it needs.
If multiple plugins try to bind the same thing you could always
encapsulate a plugin in a private module and only expose a limited set of
bindings.
If I miss the point here then maybe try to explain why you are passing
bindings in properties files...
Thank you.
Yes I looked at Multibinders but this still requires the brute force
approach. Each of my plugins can register any random object, I don't know
the universe of interfaces before hand. I was more looking in the direction
of somehow tapping into how the bindings are processed so that when Guice
calculate that binding on demand?
Is this or something like that possible?
Thanks

Post by Stephan Classen
You could have a look at multi binders.
https://github.com/google/guice/wiki/Multibindings
Then bind all possible implementations of an interface and use the value
from the properties to select the one out of the set.
Hello,
I have a case in which a portion of the binding are dynamically provided
exampleService=ExampleServiceImpl
fooService=FooServiceImpl
Unlike Guice's approach, the key is not a type but an actual Name. For
now, I'm just binding those concrete types to themselves, like
*bind(FooServiceImpl.class).to(bindFooServiceImpl.class)*
Of course this approach doesn't work because then the following injection
public class Foo {
@Inject
private FooService fooService;
}
There's no default way in which Guice would figure out that FooService
can actually be served by FooServiceImpl. The alternative that I have
thought about so far is to introspect those types and generate bindings for
each superclass and implemented interface.
I was wondering is there's a less "brute force" approach.
Thanks
--
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
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--

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
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch
<https://groups.google.com/d/msgid/google-guice/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
<http://www.mulesoft.com/>
Mariano Gonzalez
Principal Lead Engineer

Juan Manso 999 6th floor, Buenos Aires, Argentina C1107CBT

O [phone]

<https://www.linkedin.com/company/www.mulesoft.com>
<https://twitter.com/mulesoft> <https://www.facebook.com/MuleSoft>
<https://www.youtube.com/user/mulesoftvids> We're hiring!
<http://www.mulesoft.com/careers>

[Stephan Classen]

I guess then you are on your own.

I don't think Guice provide such a feature out of the box.
You could write a custom Module which reads the properties files and
creates bindings for each and every one.
As long as all of them are simple just like the examples you gave I
think you should be able to get this done in a few lines of code.
But I don't know Spring enough to tell if there are complex cases which
you would also need to support...

Good luck

And if you have any concrete question don't hesitate to ask

Post by 'Mariano Gonzalez' via google-guice
The reason for binding as properties is basically backwards
compatibility. This is a legacy system originally built with spring.
I'm trying to move to guice because spring is way too heavy and takes
a long time to start, but all of this works out of the box.
Unfortunately, having each plugin ship with a module is not an option
in this case, which is why I'm looking for a way to leverage guice
goodies while while keeping spring's behavior.
Thanks
I don't think this would be a good approach. And I am not even
sure if guice would allow it.
I would rather propose that every plugin comes with a Module which
is then passed to the injector creation method.
This way every plugin can bind whatever it needs.
If multiple plugins try to bind the same thing you could always
encapsulate a plugin in a private module and only expose a limited
set of bindings.
If I miss the point here then maybe try to explain why you are
passing bindings in properties files...

Post by 'Mariano Gonzalez' via google-guice
Thank you.
Yes I looked at Multibinders but this still requires the brute
force approach. Each of my plugins can register any random
object, I don't know the universe of interfaces before hand. I
was more looking in the direction of somehow tapping into how the
bindings are processed  so that when Guice realises that it
that binding on demand?
Is this or something like that possible?
Thanks
You could have a look at multi binders.
https://github.com/google/guice/wiki/Multibindings
Then bind all possible implementations of an interface and
use the value from the properties to select the one out of
the set.

Post by 'Mariano Gonzalez' via google-guice
Hello,
I have a case in which a portion of the binding are
dynamically provided through a properties file with the
|
exampleService=ExampleServiceImpl
fooService=FooServiceImpl
|
Unlike Guice's approach, the key is not a type but an actual
Name. For now, I'm just binding those concrete types to
themselves, like
/bind(FooServiceImpl.class).to(bindFooServiceImpl.class)/
Of course this approach doesn't work because then the
|
publicclassFoo{
@Inject
privateFooServicefooService;
}
|
There's no default way in which Guice would figure out that
FooService can actually be served by FooServiceImpl. The
alternative that I have thought about so far is to
introspect those types and generate bindings for each
superclass and implemented interface.
I was wondering is there's a less "brute force" approach.
Thanks
--
You received this message because you are subscribed to the
Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails
Visit this group at
https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/7d2ec09b-9702-4615-85f2-82f47329c9b5%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
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,
To post to this group, send email to
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com
<https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

--
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,
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch
<https://groups.google.com/d/msgid/google-guice/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
<http://www.mulesoft.com/>
Mariano Gonzalez
Principal Lead Engineer
Juan Manso 999 6th floor, Buenos Aires, Argentina C1107CBT
O [phone]
<https://www.linkedin.com/company/www.mulesoft.com>
<https://twitter.com/mulesoft> <https://www.facebook.com/MuleSoft>
<https://www.youtube.com/user/mulesoftvids> We're hiring!
<http://www.mulesoft.com/careers>
--
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
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-guice/CAB_6cf5BrHWXzNE%3DhSC_5jjqFQDuPKbhuBk4fFepSXbxE68OkA%40mail.gmail.com
<https://groups.google.com/d/msgid/google-guice/CAB_6cf5BrHWXzNE%3DhSC_5jjqFQDuPKbhuBk4fFepSXbxE68OkA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.