Re: Dynamic binding inference

[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



On 19.06.2018 17:17, 'Mariano Gonzalez' via google-guice wrote:
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

On Tue, Jun 19, 2018, 12:09 PM Stephan Classen > wrote:


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



On 19.06.2018 16:45, 'Mariano Gonzalez' via google-guice wrote:

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

On Tuesday, June 19, 2018 at 11:36:08 AM UTC-3, scl wrote:

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.



On 19.06.2018 16:33, 'Mariano Gonzalez' via google-guice wrote:

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:

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


-- 
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+unsubscr...@googlegroups.com
.
To post to this group, send email to
google-guice@googlegroups.com .
Visit this group at 

Re: Dynamic binding inference

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

On Tue, Jun 19, 2018, 12:09 PM Stephan Classen  wrote:

> 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...
>
>
>
> On 19.06.2018 16:45, 'Mariano Gonzalez' via google-guice wrote:
>
> 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
>
> On Tuesday, June 19, 2018 at 11:36:08 AM UTC-3, scl wrote:
>>
>> 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.
>>
>>
>>
>> On 19.06.2018 16:33, 'Mariano Gonzalez' via google-guice wrote:
>>
>> 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
>> --
>> 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.
>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to google-guice@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/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com
> 
> .
> 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
> email to google-guice+unsubscr...@googlegroups.com.
> To post to this group, send email to google-guice@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/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch
> 

Re: Dynamic binding inference

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




On 19.06.2018 16:45, 'Mariano Gonzalez' via google-guice wrote:

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

On Tuesday, June 19, 2018 at 11:36:08 AM UTC-3, scl wrote:

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.



On 19.06.2018 16:33, 'Mariano Gonzalez' via google-guice wrote:

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:

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


--
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+unsubscr...@googlegroups.com 
.
To post to this group, send email to google-guice@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/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com 
.

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 email 
to google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@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/f2c8a553-ea1c-95c7-5e39-8cd319eb78fe%40gmx.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic binding inference

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

On Tuesday, June 19, 2018 at 11:36:08 AM UTC-3, scl wrote:
>
> 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.
>
>
>
> On 19.06.2018 16:33, 'Mariano Gonzalez' via google-guice wrote:
>
> 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
> -- 
> 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.
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@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/c528fae0-28b9-41fa-a08f-7635416ff42f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic binding inference

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




On 19.06.2018 16:33, 'Mariano Gonzalez' via google-guice wrote:

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:


|
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 
an email to google-guice+unsubscr...@googlegroups.com 
.
To post to this group, send email to google-guice@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.


--
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@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/09b132e0-2d0b-40ac-2537-16b5a88f7d77%40gmx.ch.
For more options, visit https://groups.google.com/d/optout.