date:20180619

Re: Dynamic binding inference

2018-06-19 Thread '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
>

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
.

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

2018-06-19 Thread '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

2018-06-19 Thread 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.

Dynamic binding inference

2018-06-19 Thread '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

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

Re: Guice injection not working in web application

2018-06-19 Thread Thomas Broyer



On Tuesday, June 19, 2018 at 12:44:07 AM UTC+2, scl wrote:
>
> Unless you tell guice that a dependency is optional it will never inject 
> null. It would fail with an exception if it could not fullfil a dependency.
>
> So for me the most likely cause of you seeing null is that the instance 
> you are inspecting is created by calling new, using reflection or by 
> another DI framework (like CDI or Spring).
>
> Best strategy to debug this would be to make the field
> _bankAccountProvider final. Then create a constructor to pass in the 
> instance and annotate the constructor with @Inject.
>
> Now you can place a breakpoint in the constructor. This will show you who 
> is creating the instance. And if somebody is calling new the compiler may 
> already tell you before you execute the code.
>

…and in case something else than Guice has to create the instance, then you 
can injectMembers on the instance to have the fields (and methods) injected 
by Guice; either using a MembersInjector 

 
(that you could have @Inject⋅ed into your Provider) or 
Injector#injectMembers 

 
(which implies that you have access to the Injector at that point; the 
Injector can be @Inject⋅ed too into your provider, but I'd recommend using 
a MembersInjector instead).
 

> By the way: I would always favour constructor injection over field 
> injection
> - because it makes writing tests simpler (just call the constructor from 
> your test class)
> - an ugly constructor with 5+ arguments smells stronger than 5+ fields 
> with annotation. And this is good because having that many dependency is 
> often a sign that a class has too many responsebilities...
>

+1
see also https://github.com/google/guice/wiki/MinimizeMutability (and other 
best practices in the wiki)
 

>
> Am 18. Juni 2018 17:19:46 MESZ schrieb Adil Quraish  >:
>>
>> I am trying to get Guice to work in a web application deployed on JBoss 
>> EAP 6.4 When I try to step through the Guice code, I notice that the 
>> binding is happening. However, when I try to inject the bound object, I 
>> always get null. The following are the code changes I have done to enable 
>> Guice -
>>
>>
>> 1) *web.xml*
>>
>> 
>> com.univeris.guice.GuiceConfig
>> 
>>
>> 
>> guiceFilter
>> com.google.inject.servlet.GuiceFilter
>> 
>>
>> 
>> guiceFilter
>> /*
>> 
>>
>>
>> 2) *GuiceConfig*
>>
>> @Singleton
>> public class GuiceConfig extends GuiceServletContextListener {
>> @Override
>> protected Injector getInjector() {
>> Injector injector = Guice.createInjector(
>> new ServletModule() {
>> @Override
>> protected void configureServlets() {
>> serve("/uif/*").with(UIFInitializeServlet.class);
>> serve("/upm/*").with(IDPServlet.class, 
>> ImmutableMap.of("instance-name","upm"));
>> serve("/uiw/*").with(IDPServlet.class, 
>> ImmutableMap.of("instance-name","uiw"));
>> }
>> },
>> new MainModule()
>> );
>>
>> return injector;
>>   }
>> }
>>
>>
>> 3) *MainModule*
>>
>> public class MainModule extends AbstractModule {
>>
>> @Override
>> protected void configure() {
>> install(new BankAccountModule());
>> install(new CoreModule());
>> }
>> }
>>
>>
>> 4) *BankAccountModule*
>>
>> public class BankAccountModule extends AbstractModule {
>> @Override
>> protected void configure() {
>>  bind(BankAccountProvider.class).toProvider(BankAccountGuiceProvider.class); 
>>  
>>  bind(BankAccountService.class).toProvider(BankAccountServiceProvider.class);
>> }
>> }
>>
>>
>> 5) *BankAccountGuiceProvider*
>>
>> public class BankAccountGuiceProvider implements 
>> Provider {
>> @Override
>> public BankAccountProvider get() {
>> return ProviderLocator.locateProvider(BankAccountProvider.class);
>> }
>> }
>>
>>
>> 6) *BankAccountServiceUVS*
>>
>> @Stateless
>> @Interceptors(ServiceInterceptor.class)
>> public class BankAccountServiceUVS implements BankAccountService {
>>
>> @Inject
>> private BankAccountProvider _bankAccountProvider;
>>
>> @Override
>> public BankAccountCollection getAllBankAccounts(final Integer entityId, 
>> final String entityType) {
>> BankAccountCollection retVal = 
>> _bankAccountProvider.getAllBankAccounts(entityId, 
>> return PojoHelper.cloneObject(retVal);
>> }
>> }
>>
>>
>> The *_bankAccountProvider* is always injected as null. I have been 
>> pouring through several forums for several days to no avail. Can someone 
>> point out what I am missing?
>>
>>

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

Re: Dynamic binding inference

Re: Dynamic binding inference

Re: Dynamic binding inference

Re: Dynamic binding inference

Dynamic binding inference

Re: Guice injection not working in web application

6 matches

Site Navigation

Mail list logo

Footer information