Injection by condition

2013-09-19 Thread Alex Khomchenko
Hello everyone. Sorry for my bad English. I have a problem with injection condition. There is custom made MultitenancyPersistence and I want to use different persistence units for different repository. Here is my code: I've got: public class MultiTenantPersistServiceImpl implements

Remote injection - Service Architecture Model

2013-09-19 Thread Paweł Cesar Sanjuan Szklarz
Hello. I have created a library to inject dependencies remotely, I call it Service Architecture Model (SAM). Logically it works as a injector that is split over several JVM machines. The modules used to create the remote injector are standard guice modules. To build the remote injector some

Tripping up on Bindings that are never used

2013-09-19 Thread Eric Tschetter
Hello Guicers, I'm running into a bit of a problem that I was wondering if someone from the Guice community might have some great insight into how to deal with it. I have a project that is an open distributed analytical data store ( http://www.druid.io) and I've been guicifying it in order to

Re: Injection by condition

2013-09-19 Thread Stephan Classen
If I understood your question correctly, the answer is no. There is no way to do this. But to make sure I didn't miss read your question: - AbstractRepo requires MTUnitOfWork - MTUnitOfWork requires MTPersistServiceImpl - MTPersistServiceImpl requires @Named(PersistConsts.JPA_UNIT_NAME) What

Re: Tripping up on Bindings that are never used

2013-09-19 Thread Nate Bauernfeind
I think this is the easiest way to do this (written in Scala purely for terseness): class A class B @Inject() (a: A) class TestModule extends PrivateModule { def configure() {} @Provides def createB(a: Provider[A]): B = { new B(a.get()) } } If you change Provider[A] to A you get

Re: Tripping up on Bindings that are never used

2013-09-19 Thread Nate Bauernfeind
Also, I might recommend allowing your extensions to implement two separate configuration methods -- one for the historical injector and the other for your broker injector. Then, something like you're explaining would easily be covered or explained as a bug in the contract between your design and

Re: Tripping up on Bindings that are never used

2013-09-19 Thread Eric Tschetter
Hrm, the thing with the suggestion of switching to Providers is that the broker won't even have a binding to a provider, so I'm pretty sure (haven't tried yet) that it will fail out saying that it doesn't know how to create that Provider. I thought about creating separate methods for the

Re: Tripping up on Bindings that are never used

2013-09-19 Thread Sam Berlin
FYI, if you're looking to prevent injecting things that don't have a constructor annotated with @Inject, you want to use requireAtInjectOnConstructors (which I think is only available in the beta release). requireExplicitBindings requires that there's a bind statement for the binding, but the

Method Interceptor with Annotation Arguments

2013-09-19 Thread Sasha Bermeister
Hi all, I've been following the tutorial on AOP at https://code.google.com/p/google-guice/wiki/AOP. In the tutorial, it shows how to use an annotation with no arguments: public class RealBillingService implements BillingService { @NotOnWeekends public Receipt chargeOrder(PizzaOrder order,