Home → Robotlegs 2 →

Robotlegs2 compatibility with Robotlegs1 ?

• Edit

eric.helier

01 Jul, 2013 08:17 AM

Hi,

I didn't fint any info about eventual compatibility problems with modules/libraries built with Robotlegs1.
When i try to compile a RobotLegs2 application using a RobotLegs1 component library, i got this error :
VerifyError: Error #1053: Illegal override of applicationDomain in org.robotlegs.adapters.SwiftSuspendersInjector.

I suspect this may work with correct applicationDomain configuration of v1/v2 contexts, but i'm a bit lost.

1. 1 Posted by eric.helier on 01 Jul, 2013 10:48 AM

   

   After some investigations, i eventually made it work together using a Loader/LoaderContext with a new ApplicationDomain instance, instead of linking the Robotlegs1 library at compile time.

   I'm now stuck as my Robotlegs1 library refers to a native extension wrapper, that is linked with the Robotlegs2 application, and ExtensionContext.createExtensionContext fires a SecurityDomain error :
   Error: Error #2113: Provided parameter LoaderContext.SecurityDomain is from a disallowed domain. at flash.external::ExtensionContext$/_createExtensionContext()

   • Edit

2. Support Staff 2 Posted by Ondina D.F. on 01 Jul, 2013 04:11 PM

   

   Hi Eric,

   That might be a bug:

   http://forums.adobe.com/message/4627982#4627982
   https://bugbase.adobe.com/index.cfm?event=bug&id=2999894

   Have you already tried Adobe's suggestion?
   [Adobe]

   If the loaded content is a SWF file written with ActionScript 3.0, it cannot be cross-scripted by a SWF file in another security sandbox unless that cross-scripting arrangement was approved through a call to the System.allowDomain() or the System.allowInsecureDomain() method in the loaded content file.

   http://kb2.adobe.com/cps/142/tn_14213.html

   Ondina

   • Edit

3. 3 Posted by eric.helier on 01 Jul, 2013 07:28 PM

   

   Hi Ondina,

   Thank you for your help.
   As i understand, the call to ExtensionContext.createExtensionContext should be in the main application sandbox. So i'm stuck with Robotlegs1 for now, as the project where this call is done is a core library project build with Robotlegs1, that i cannot migrate right now.

   But except the NativeExtension part of the problem, loading a Robotlegs1 swf with a "new ApplicationDomain" LoaderContext worked well.

   So for this AIR project i'm working on, i will stick to the same RobotLegs version...

   • Edit

4. Support Staff 4 Posted by Ondina D.F. on 02 Jul, 2013 06:51 AM

   

   Hey Eric,

   No problem!

   As i understand, the call to ExtensionContext.createExtensionContext should be in the main application sandbox.

   Hmm. You’ve tried all the solutions from the links and couldn’t make it work? Can you reproduce the issue in a simple application, w/o robotlegs or any other libraries?

   • Edit

5. 5 Posted by eric.helier on 02 Jul, 2013 08:11 AM

   

   I think what i'm trying to do with Native Extension calls circumvent in some way the rule expressed here by Adobe :
   https://bugbase.adobe.com/index.cfm?event=bug&id=2999894

   "The ExtensionContext class is accessible only from the ActionScript code that makes up an extension. It is not possible for an application to circumvent the ActionScript API for an extension and directly invoke the extension's native methods."

   About RobotLegs1/RobotLegs2 living together, am i right that there is now way to make it cohabit at compile time ? I mean without using Loader/LoaderContext approach, but using for example a simple library project.

   • Edit

6. Support Staff 6 Posted by Ondina D.F. on 02 Jul, 2013 01:52 PM

   

   Eric, would you mind creating a robotlegs account? Your posts keep getting stuck in the spam filter for some reason. We don’t get email notifications about the posts landing in forum’s spam folder, so we can restore the false positives only when we are logged in.

   About RobotLegs1/RobotLegs2 living together, am i right that there is now way to make it cohabit at compile time ? I mean without using Loader/LoaderContext approach, but using for example a simple library project.

   I haven’t tried it out myself, but I think that you’d encounter the same problem (Illegal override of applicationDomain) with an rl1 project loaded as a library, because of the different Swiftsuspenders versions.

   Hopefully Shaun will have some ideas on how to solve this.

   • Edit

7. Support Staff 7 Posted by Ondina D.F. on 02 Jul, 2013 03:41 PM

   

   I’ve tried loading an rl1 library project (swc) in an rl2 app. To make it work I used the rl1 source and swiftsuspenders source that works with rl1. I did something terrible to it, i.e. I renamed the Injector to something else :P And voilà, it works in an rl2 project + swiftsuspenders 2.

   • Edit

8. 8 Posted by eric.helier on 02 Jul, 2013 07:12 PM

   

   Hi ondina,

   I created the robotlegs account, sorry for the spam work.

   I renamed the Injector to something else :P And voilà You mean like creating a compatibility RL1 branch ? That may be a solution in some use case where migrating everything together is too complicated like mine.

   Thank your for taking the time to test and find a solution for this.

   I will try to investigate a bit more the Native Extension part, and see with a simple project if it's possible to "compartiment" the Native Extension AS3 wrapper in a different applicationDomain, but it is not related to RobotLegs specifically.

   For RobotLegs, my use case actually is that i am maintaining several AS3 API/SDK in use in many projects, that where built with a specific RL1 version.
   When using those APIs in our projects, i'd like to be able to use a newer RL version without migrating everything.
   So the Loader/LoaderContext approach seems my best option for this, and a benefit of this approach could be when delivering the SDK to clients, that the core part of it could be hosted on our servers, and loaded at runtime. So we could update our core on every projects in production.
   Plus it won't force our clients to develop with the same RL version also.

   • Edit

9. Support Staff 9 Posted by Ondina D.F. on 03 Jul, 2013 07:15 AM

   

   Hi Eric,

   You mean like creating a compatibility RL1 branch ? That may be a solution in some use case where migrating everything together is too complicated like mine.

   Yes. The changes have to be done in both libs, robotlegs and swiftsuspenders, but with a good IDE that wouldn’t be a problem. Maybe it would suffice to change swiftsuspenders’ package name and update the references…?

   I will try to investigate a bit more the Native Extension part, and see with a simple project if it's possible to "compartiment" the Native Extension AS3 wrapper in a different applicationDomain, but it is not related to RobotLegs specifically.

   Yes, it’s not a robotlegs problem, but if you find a solution, please let us know about it. It might help others in similar situations.

   I’m going to close this for now, but as a registered user you can re-open the discussion at any time :)

   Cheer,

   Ondina

   • Edit

10. Ondina D.F. closed this discussion on 03 Jul, 2013 07:15 AM.

11. eric.helier re-opened this discussion on 10 Jan, 2014 01:57 PM

12. 10 Posted by eric.helier on 10 Jan, 2014 01:57 PM

    

    Some month later, i've been confronting again to the same problem.
    I thought i would add the info here in case someone else is interested : following your last idea about renaming swiftsuspender's package name worked very well.
    So I made myself a "compatibility" version of robotlegs1.5 sources with swiftsuspenders1.6 renamed package, and everything is alright now.
    I may publish this compatibility version of robotlegs/swiftsuspender on github if anyone interested.

    • Edit

13. Support Staff 11 Posted by Ondina D.F. on 11 Jan, 2014 12:02 PM

    

    Hi Eric,

    I may publish this compatibility version of robotlegs/swiftsuspender on github if anyone interested.

    Yes, that would be great! Please post the link in here.Thanks.

    Ondina

    • Edit

14. Support Staff 12 Posted by Ondina D.F. on 22 Jan, 2014 03:26 PM

    

    Eric, I'm going to mark this as resolved. When/if you want to share your "compatibility" version of robotlegs, you can re-open this discussion and post the link.

    Cheers,
    Ondina

    • Edit

15. Ondina D.F. closed this discussion on 22 Jan, 2014 03:26 PM.