Child injector rules and Lazy initialization
I have an issue with SwiftSusperder,
Robotlegs and a module library (not joelhooks' lib but
a self-made).
I used child injectors but lazy initialization cause bad injection
with eventDispatcher field.
Here's my issue roots:
You have two classes like that:
public class RequiredObject {
}
public class ComposedObject {
[Inject] public var requirement:RequiredObject;
}
And this is the way I map them:
var parent:Injector = new SamInjector();
parent.mapSingleton(RequiredObject);
parent.mapSingleton(ComposedObject);
var child:Injector = parent.createChildInjector();
child.mapSingleton(RequiredObject);
My issue is : if I use ComposedObject the first time a child module, or in the parent module, the result is not the same
var composed:ComposedObject = child.getInstance(ComposedObject);
composed.requirement // != parent.getInstance(RequiredObject);
Whereas
var composed:ComposedObject = parent.getInstance(ComposedObject);
composed.requirement // == parent.getInstance(RequiredObject);
Now imagine RequiredObject is the EventDispatcher
and ComposedObject an Actor...
It seems InjectionConfig and overriding
Injector::getMapping is the way to go,
but I don't know how to implement this (my attempts have failed
miserably).
Overriding Injector::map* methods to create
instantly the instances works, but I need lazy instantiation.
Thanks.
Comments are currently closed for this discussion. You can start a new one.
Support Staff 2 Posted by Ondina D.F. on 19 Jul, 2012 07:26 AM
Hi Samuel,
Sorry for the late response, but I hoped that Till, Stray or Shaun would answer your question. I’ve notified them, but they are probably busy with rl2…
Could it be that the problem is caused by your custom injector not knowing which ApplicationDomain to use?
How does your SamInjector() look like?
The original Injector createChildInjector method looks like this:
3 Posted by Samuel Déal on 19 Jul, 2012 09:11 AM
Thank's Ondina.
About SamInjector, sorry, it's a rest of my tests.
The problem exits with the base Injector class.
Few additional informations:
I use robotlegs 1.5.2 (based on SwiftSuspender 1.6.0 if I remember).
I've tryed with [master] branch of Swift Suspender (tschneidereit github repo) and the issue still persists.
Support Staff 4 Posted by Ondina D.F. on 19 Jul, 2012 11:55 AM
Samuel,
I might be very wrong, but you have these mappings:
parent.mapSingleton(RequiredObject);
and
child.mapSingleton(RequiredObject);
Since the child injector has already a mapping, RequiredObject, mpped in the parent, won’t be used.
“The child injectors forward all injection requests they don’t have a mapping for to their parent injector.“
From here: https://github.com/tschneidereit/SwiftSuspenders/blob/childinjector...
Support Staff 5 Posted by Till Schneidereit on 19 Jul, 2012 12:21 PM
Hey Samuel,
sorry for not replying earlier - I missed this post.
Can you try the Robotlegs build here:
https://github.com/tschneidereit/robotlegs/downloads and see if that
changes things? It contains Swiftsuspenders 2 and I think I remember
fixing an issue that sounded a lot like yours.
cheers,
till
6 Posted by Samuel Déal on 19 Jul, 2012 12:22 PM
Yes, this is my issue.
I need diffenrent RequiredObject per injector, but I would like the objects originaly mapped in parent to be injected with parent instances of dependencies.
The child injector forward the instanciation of ComposedObject to it's parent, but don't forward the 'hydratation' (I mean fulfill all the injection points of the new instance, is this word understandable?)
I would my child injectors to forward both to parent if they don't have themselves the ComposedObject definition.
I think a custom rule can do that, but I failed implementing it.
7 Posted by Samuel Déal on 19 Jul, 2012 12:35 PM
Hi Till, thank you for responding
I've just tried with this swc and the issue still persists.
I would like to say it's not necessarily a bug, juste an behavior of swiftSuspender I would like to override.
I don't know which behavior you think is the most natural.
Ondina D.F. closed this discussion on 27 Aug, 2012 10:38 AM.