Actually found an incredible simple way to do this:
def configure() {
var a = someObj()
val dummyObj = new Object {
@Inject
def whateverName(f: TheDependency) = {
f.add(a)
}
}
requestInjection(dummyObj );
}
On Wed, Mar 12, 2014 at 10:35 PM, Nate Bauernfeind <
[email protected]> wrote:
> I agree. If these objects weren't meant to exist throughout the life of my
> application then binding them as singletons is not a good idea.
> Additionally, you wouldn't want the listener subscription to last forever
> either. I instead move subscribe and unsubscribe into start and stop
> methods. In cases like this I have found two options for injection. For
> most cases I use an AssistedInject factory since I still want guice
> injections but I'll typically create multiple instances keyed by something
> (like user or client). On a recent project I actually wanted to create a
> rich sub-graph of objects per client, so I actually created a childInjector
> where I had a 'ServiceName' token bound and I was able to remove most of
> the assisted inject factories. I injected those objects as eager singletons
> in the childInjector, but without the registerThing injection. Instead I
> call start and stop on every object in the subgraph as a client was being
> provisioned and deprovisioned.
>
> So, I guess I don't mind paying for the increased start-up time and the
> extra map entries if it means I don't have to do any manual dependency
> management.
>
> I also wouldn't call this pattern a decoupled pattern. IMO, this is still
> quite coupled. The listener has to 1) implement an interface defined by the
> service (either directly, with a static inner class, or use some arbitrary
> implementation) and 2) it has to inject the service that it wants to listen
> to (which the pattern I showed tries to hide). So the listener still has to
> know enough of the service.
>
> A decoupled approach would be the eventbus solution I talked about earlier
> in the thread; in that case both parties only need to know about the event
> bus and the message models/types. In this model it doesn't matter who's
> generating the content or who's consuming the content. Whereas in the case
> where the service maintains a listener list/mapping then there really can
> only be one generator.
>
> Nate
>
>
> On Wed, Mar 12, 2014 at 1:29 PM, Dirk Olmes <[email protected]>wrote:
>
>> > On 03/10/2014 09:27 PM, Nate Bauernfeind wrote:
>> > > 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()
>> >
>> > Great trick. But now you're left with pointless Thing1 and Thing2
>> > instances in the Injector. For only 2 instances that's not worth the
>> > hassle but in my case they may become hundreds ...
>> >
>> > Interesting! Have you found a significant performance overhead? I tend
>> > to hide bindings like these in a private module, but I doubt that would
>> > make their cost any cheaper. Can you explain what the cons are from this
>> > approach? I do things like this all the time now.
>>
>> Before adopting an approach that you describe I try to think about the
>> "cost" of it. In your case that's additional instances bound to the
>> injector and retained throughout the entire lifetime of the Injector. Im
>> my case that's as long as the app lives.
>>
>> Now an object here and there and a few extra bindings might be worth the
>> decoupling you gain from this approach.
>>
>> -dirk
>>
>> --
>>
>> 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 a topic in the
> Google Groups "google-guice" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-guice/HMj5hmPjmR4/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>
--
Med venlig hilsen/Best regards
Mikkel Petersen
Jagtvej 82 4th
2200 København N
Telefon 35 37 63 10
Mobil 91 97 03 64
--
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.
