@Provides provideFoo(MembersInjector<Foo> fooInjector) {
Foo foo = new Foo();
fooInjector.injectMembers(foo);
return foo;
}
Also answered
here<http://stackoverflow.com/questions/4844101/how-to-inject-things-on-objects-that-were-created-using-reflection>
.
sam
On Mon, Mar 10, 2014 at 6:37 PM, Mikkel Petersen <[email protected]> wrote:
> Im not sure what you mean could you post a small example ?
>
> Den mandag den 10. marts 2014 23.28.52 UTC+1 skrev Sam Berlin:
>>
>> FYI, injecting a MembersInjector<World> into the '@Provides provideWorld'
>> and calliing injectMembers(world) will remove the need to do the
>> requestInjection in configure.
>>
>> sam
>>
>>
>> On Mon, Mar 10, 2014 at 6:11 PM, Mikkel Petersen <[email protected]>wrote:
>>
>>> in case anyone has the same problem..this is my solution so far (a real
>>> world example)
>>>
>>> class WorldPhysXModule extends Module {
>>> val world: WorldPhysX = new WorldPhysX
>>> @Provides
>>> @Singleton
>>> @Named("dimensionScale") def dimensionScale(settings: IProperties):
>>> Float = settings.getFloat("dimensionScale")
>>>
>>> @Provides
>>> @Singleton
>>> def provideWorld(settings: IProperties) = {
>>> val subStep1: Float = 1f / settings.getFloat("subStep1")
>>> val subStep2: Int = settings.getInt("subStep2")
>>> world.setGravity(0, settings.getFloat("gravity"), 0)
>>> world.setTiming(subStep1, subStep2)
>>> world.setStepSize(settings.getFloat("stepSize"))
>>> world.setEnableContactUserReport(true)
>>> world;
>>> }
>>> def configure(binder: Binder) {
>>> binder.requestInjection(binder)
>>> binder.requestInjection(world);
>>> binder.bind(classOf[GroundPlaneActor]).toInstance(new
>>> GroundPlaneActor(world, "groundPlane", 1000, 0.00f))
>>> }
>>>
>>> }
>>>
>>> Note that "WorldPhysx" does not know anything about guice, so we have to
>>> access the setters directly..
>>> To ensure that also "World" gets injected, call requestInjection in
>>> configure but dont BIND it here..do that in provides..anyway that's my
>>> fifty cent.
>>>
>>> Den mandag den 10. marts 2014 22.36.27 UTC+1 skrev Mikkel Petersen:
>>>
>>>> Still, since not all classes are injectable (third party) you might
>>>> need to access them and populate them manually..
>>>>
>>>> Den mandag den 10. marts 2014 21.27.38 UTC+1 skrev Nate Bauernfeind:
>>>>>
>>>>> No actually you don't get already bound exceptions. Guice actually
>>>>> treats the injection as a setter based injection (it doesn't care how you
>>>>> name methods; but I tend to use the word register since it seems to
>>>>> suggest
>>>>> not saving the object).
>>>>>
>>>>> So if you're thinking on the Abstract case you'd have something like
>>>>> this:
>>>>>
>>>>> abstract class AbstractThing {
>>>>> @Inject
>>>>> private void registerThing(ThingService service) {
>>>>> service.registerThing(this) }
>>>>> }
>>>>>
>>>>> class Thing1 extends AbstractThing {
>>>>> ...
>>>>> }
>>>>>
>>>>> class Thing2 extends AbstractThing {
>>>>> ...
>>>>> }
>>>>>
>>>>> and in your configure method you can just do:
>>>>>
>>>>> bind(Thing1.class).asEagerSingleton()
>>>>> bind(Thing2.class).asEagerSingleton()
>>>>>
>>>>> And the magic just happens. It doesn't matter if Thing1/Thing2 are in
>>>>> the same module or separate modules as long as the ThingService exists
>>>>> somewhere and are being created as part of the same injector. And note
>>>>> that
>>>>> the private classifier allows you to hide the fact that Guice is going to
>>>>> do this for you. So you never have to worry about users of Thing1/Thing2
>>>>> abusing that method (at-least I like making it private; your milage may
>>>>> vary =P).
>>>>>
>>>>> If you bind AbstractThing to Thing1 and to Thing2 you will get an
>>>>> already bound exception. But the AbstractThing class doesn't need to show
>>>>> up in any bindings for the injection to occur.
>>>>>
>>>>> Good luck,
>>>>> Nate
>>>>>
>>>>> On Mon, Mar 10, 2014 at 3:15 PM, Mikkel Petersen <[email protected]>wrote:
>>>>>
>>>>>> This sounds like a good idea but wont to get a "Already bound"
>>>>>> exception ?
>>>>>>
>>>>>>
>>>>>> Den mandag den 10. marts 2014 20.26.26 UTC+1 skrev Nate Bauernfeind:
>>>>>>
>>>>>>> Just finished reading through the stack overflow link; thanks for
>>>>>>> sharing it. It reminded me of the following:
>>>>>>>
>>>>>>> I've heard/read/adopted the policy that guice modules should
>>>>>>> sincerely avoid any conditional logic. If you do find yourself with some
>>>>>>> conditional logic try and split your module up by either moving the
>>>>>>> conditional logic into a provider or up into multiple modules and let
>>>>>>> your
>>>>>>> application choose which module(s) based on the appropriate mode(s).
>>>>>>> It's
>>>>>>> hard to do, and I probably don't have one project that is conditional
>>>>>>> free
>>>>>>> in all configure methods... but that certainly helps defer the need to
>>>>>>> inject some things into a guice module.
>>>>>>>
>>>>>>> Next, I wanted to point out one pattern I've used quite often when
>>>>>>> it comes to registering objects for some purpose (like listening to
>>>>>>> events,
>>>>>>> or even to enable key-based delegation to that object). Typically you'll
>>>>>>> have a main service you want to register to listen/subscribe on, which
>>>>>>> I'll
>>>>>>> use the example of a DaoService. Users of the DaoService can subscribe
>>>>>>> to
>>>>>>> the Dao to listen for events that occur on any sub-class of a type. So
>>>>>>> some
>>>>>>> handwaving:
>>>>>>>
>>>>>>> class DaoService {
>>>>>>> public synchronized void addListener(Class<T> type,
>>>>>>> DaoListener<T> listener) {...}
>>>>>>> }
>>>>>>>
>>>>>>> public interface DaoListener<T> {
>>>>>>> public void dataAdded(T data) throws Exception;
>>>>>>> public void dataUpdated(T oldData, T newData) throws Exception;
>>>>>>> public void dataRemoved(T data) throws Exception;
>>>>>>> }
>>>>>>>
>>>>>>> And then in my user class (and sometimes this is an abstract base
>>>>>>> class) I use setter injection specifically to register the listener:
>>>>>>>
>>>>>>> class ExampleUser {
>>>>>>> private Listener _listener = new Listener();
>>>>>>>
>>>>>>> @Inject
>>>>>>> public ExampleUser(...) {...}
>>>>>>>
>>>>>>> @Inject
>>>>>>> private void registerAsDaoListener(DaoService service) {
>>>>>>> service.addListener(MyDataType.class, _listener);
>>>>>>> }
>>>>>>>
>>>>>>> private final class Listener implements DaoListener<MyDataType> {
>>>>>>> ...
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> So, again, in this example I'm decoupling the idea of who is
>>>>>>> listening to what data. Obviously the sender / daoService needs to be
>>>>>>> around (unlike in the event bus example), but now no one ever needs to
>>>>>>> know
>>>>>>> about how many listeners there are (depending on how you store your
>>>>>>> listeners you may need to make sure you're not overwriting any other
>>>>>>> listener in the addListener method).
>>>>>>>
>>>>>>> And.. I also use Scala as often as I can, so sometimes pieces of
>>>>>>> these end up in a trait that is easy to mix-in for the repeated
>>>>>>> functionality (like managing the listener map/list).
>>>>>>>
>>>>>>> So.. maybe this would be a good alternative to the multibinding
>>>>>>> extension for you. I've used it with great success (esp. when the
>>>>>>> register
>>>>>>> method is on an abstract base class).
>>>>>>>
>>>>>>> Good luck and happy Guicing =),
>>>>>>> Nate
>>>>>>>
>>>>>> --
>>>>>> 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 [email protected].
>>>>>> To post to this group, send email to [email protected].
>>>>>> Visit this group at http://groups.google.com/group/google-guice.
>>>>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/google-guice.
>>> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/google-guice.
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.
