Child ApplicationDomains break the injector
I posted this issue on the SwiftSuspenders forum but I'm posting it here just in case someone sees it and can tell us whether we're doing something wrong.
We created a RobotLegs SWF (with SwiftSuspenders) and it worked fine standalone. However, when loading this into another Robotlegs SWF (also with SwiftSuspenders) in a child ApplicationDomain at runtime, injection failed in the child SWF, throwing the following exception:
Exception fault: ReferenceError: Error #1065: Variable MyClassView is not defined.
at flash.system::ApplicationDomain/getDefinition()
at org.swiftsuspenders.injectionpoints::PropertyInjectionPoint/initializeInjection()[/Users/tschneidereit/dev/swiftsuspenders/swiftsuspenders/src/org/swiftsuspenders/injectionpoints/PropertyInjectionPoint.as:58]
So it seems that when a RobotLegs SWF using SwiftSuspenders loads another RobotLegs SWF using SwiftSuspenders in a child ApplicationDomain, injection breaks completely - it seems as though SwiftSuspenders is using the injector/injection settings from the parent domain?
Loading the SWF into the same ApplicationDomain does work, however this does open up other problems for us. We can use this as a workaround for now, but it would be great to find out whether we're doing something wrong, or whether this is an issue with SwiftSuspenders (or indeed RobotLegs). Our investigation has led us to believe this is an issue with SwiftSuspenders.
Is anyone familiar with this problem?
Hope someone can help,
Mani
Showing page 2 out of 2. View the first page
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
31 Posted by Mani on 21 Sep, 2010 10:07 PM
Thanks Joel, that explains a lot!
I'm slightly confused though - shouldn't a framework be transparent and do this sort of thing for you? If I was to, say, build a game loader in Robotlegs which loaded and unloaded games at runtime, and these games might be written by 3rd parties, I'd probably load them into separate ApplicationDomains to avoid any potential weirdness. But I would then have to stipulate that none of those games could be written in Robotlegs, which seems like a problem.
[This is the only real flaw I have come across in Robotlegs, which overall I think has such great value as a framework. As someone who has used PureMVC heavily, I can honestly say that Robotlegs is a massive improvement!]
I know that Modular Robotlegs provides a communication mechanism, so it still has its place and is still very useful, but the ApplicationDomain issue (to me anyway) shouldn't be there. Unless I'm missing something else?
Shaun - thank you! I will endeavour to give this a go tomorrow (it's pretty late here in the UK).
Mani
32 Posted by Mani on 21 Sep, 2010 10:12 PM
Joel - as an aside, if you were to post a very basic example of a Modular Robotlegs application that communicates across several SWFs that know very little about eachother (for the sake of not coupling things too much), I think it would take a lot of the guesswork out and would open Modular Robotlegs up to a wider audience. I'd definitely give it another go if you did!
Mani
Support Staff 33 Posted by Shaun Smith on 21 Sep, 2010 10:27 PM
"shouldn't a framework be transparent and do this sort of thing for you?"
Well, yes and no. We should provide better modular support out-of-the-box that's for sure. Initially I didn't write any modular stuff into the framework because I believed it to be completely trivial to implement at an app level - share an event dispatcher if you want to chat, expose interfaces for direct access, simple - but it turns out that it's not quite so simple (at least, not in terms of Application Domains and Injection).
Up until the commits in my "app-domain" branch Robotlegs has had no concept of Application Domains. Hopefully the new code will help with modular apps and utils.
34 Posted by Michal Wroblews... on 21 Sep, 2010 11:46 PM
Thanks Shaun!
We just hope to make Robotlegs better :)
It's not that late here in Poland ;) So I tested swc provided by you and it worked as it should. So it's ok.
I also think that this kind of problem shouldn't appear and it should be dealt automatically and optionally as modules
35 Posted by Mani on 22 Sep, 2010 09:16 AM
Cheers Shaun,
Will try the SWC out in a little while and report back.
Thanks for responding to my comments above - and I agree: Robotlegs probably shouldn't fail when loading other Robotlegs SWFs, however the modular stuff could (and maybe should) be considered an add-on, as it may be extra code that isn't used in the majority of cases.
Thanks again for looking at this, guys, I really appreciate it!
Mani
36 Posted by Mani on 22 Sep, 2010 09:20 AM
Hi Shaun,
Your new SWC fixes the problem - thanks!
Is there a view to merge this back into the trunk? For now we're happy to use our version but long term it might be useful...
Mani
Support Staff 37 Posted by Shaun Smith on 22 Sep, 2010 01:20 PM
Hi Mani,
That's great news! Yes, I will merge this back into master, just wanted to make sure that it actually solved the problem before packaging a new release.
Support Staff 38 Posted by Shaun Smith on 22 Sep, 2010 01:50 PM
Coolio, v1.3.0 is released. Please download it from http://www.robotlegs.org and try the release SWC. Thanks!
39 Posted by Michal Wroblews... on 22 Sep, 2010 04:52 PM
SWC works fine for me. Will look into code how you did it.
Thanks,
Michal
Support Staff 40 Posted by Shaun Smith on 22 Sep, 2010 05:06 PM
The fixes were based on your idea, but with some extra checking. See:
http://github.com/robotlegs/robotlegs-framework/blob/v1.3.0/src/org...
41 Posted by Mani on 24 Sep, 2010 02:39 PM
Thanks a lot, Shaun, very much appreciated.
Just wanted to confirm that we have now upgraded to 1.3.0, removed the workaround where we manually set the ApplicationDomain and everything is now working perfectly.
Cheers again!
Mani
Support Staff 42 Posted by Shaun Smith on 24 Sep, 2010 03:21 PM
Ah! That's good news. My pleasure =)
Shaun Smith closed this discussion on 24 Sep, 2010 03:21 PM.