Dynamic binding inference

[Mariano Gonzalez]

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.

--
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 google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

[Mariano Gonzalez]

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

[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...

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com.

[Mariano Gonzalez]

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 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch.

For more options, visit https://groups.google.com/d/optout.

--

Mariano Gonzalez Principal Lead Engineer   Juan Manso 999 6th floor, Buenos Aires, Argentina C1107CBT   O +54-11-5353-4497          We're hiring!

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAB_6cf5BrHWXzNE%3DhSC_5jjqFQDuPKbhuBk4fFepSXbxE68OkA%40mail.gmail.com.