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.
