tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/3671-robotlegs2-compatibility-with-robotlegs1Robotlegs: Discussion 2014-01-22T15:27:07Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-01T10:48:29Z2013-07-02T19:17:00ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>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.</p>
<p>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 :<br>
<code>Error: Error #2113: Provided parameter
LoaderContext.SecurityDomain is from a disallowed domain. at
flash.external::ExtensionContext$/_createExtensionContext()</code></p></div>eric.heliertag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-01T16:11:02Z2013-07-01T16:11:02ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Hi Eric,</p>
<p>That might be a bug:</p>
<p><a href=
"http://forums.adobe.com/message/4627982#4627982">http://forums.adobe.com/message/4627982#4627982</a><br>
<a href=
"https://bugbase.adobe.com/index.cfm?event=bug&id=2999894">https://bugbase.adobe.com/index.cfm?event=bug&amp;id=2999894</a></p>
<p>Have you already tried Adobe's suggestion?<br>
[Adobe]</p>
<blockquote>
<p>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.</p>
</blockquote>
<p><a href=
"http://kb2.adobe.com/cps/142/tn_14213.html">http://kb2.adobe.com/cps/142/tn_14213.html</a></p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-01T19:28:39Z2013-07-02T19:17:00ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Hi Ondina,</p>
<p>Thank you for your help.<br>
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.</p>
<p>But except the NativeExtension part of the problem, loading a
Robotlegs1 swf with a "new ApplicationDomain" LoaderContext worked
well.</p>
<p>So for this AIR project i'm working on, i will stick to the same
RobotLegs version...</p></div>eric.heliertag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-02T06:51:21Z2013-07-02T06:51:21ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Hey Eric,</p>
<p>No problem!</p>
<blockquote>
<p>As i understand, the call to
ExtensionContext.createExtensionContext should be in the main
application sandbox.</p>
</blockquote>
<p>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?</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-02T08:11:01Z2013-07-02T19:17:00ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>I think what i'm trying to do with Native Extension calls
circumvent in some way the rule expressed here by Adobe :<br>
<a href=
"https://bugbase.adobe.com/index.cfm?event=bug&id=2999894">https://bugbase.adobe.com/index.cfm?event=bug&amp;id=2999894</a></p>
<p>"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."</p>
<p>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.</p></div>eric.heliertag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-02T13:52:27Z2013-07-02T13:52:27ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>Hopefully Shaun will have some ideas on how to solve this.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-02T15:41:27Z2013-07-02T15:46:39ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>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.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-02T19:12:49Z2013-07-02T19:13:54ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Hi ondina,</p>
<p>I created the robotlegs account, sorry for the spam work.</p>
<p><code>I renamed the Injector to something else :P And
voilà</code> 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.</p>
<p>Thank your for taking the time to test and find a solution for
this.</p>
<p>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.</p>
<p>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.<br>
When using those APIs in our projects, i'd like to be able to use a
newer RL version without migrating everything.<br>
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.<br>
Plus it won't force our clients to develop with the same RL version
also.</p></div>eric.heliertag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692013-07-03T07:15:49Z2013-07-03T07:15:49ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Hi Eric,</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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…?</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>I’m going to close this for now, but as a registered user
you can re-open the discussion at any time :)</p>
<p>Cheer,</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692014-01-10T13:57:10Z2014-01-10T13:57:14ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Some month later, i've been confronting again to the same
problem.<br>
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.<br>
So I made myself a "compatibility" version of robotlegs1.5 sources
with swiftsuspenders1.6 renamed package, and everything is alright
now.<br>
I may publish this compatibility version of
robotlegs/swiftsuspender on github if anyone interested.</p></div>eric.heliertag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692014-01-11T12:02:11Z2014-01-11T12:02:11ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>Hi Eric,</p>
<blockquote>
<p>I may publish this compatibility version of
robotlegs/swiftsuspender on github if anyone interested.</p>
</blockquote>
<p>Yes, that would be great! Please post the link in
here.Thanks.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/275620692014-01-22T15:26:55Z2014-01-22T15:26:55ZRobotlegs2 compatibility with Robotlegs1 ?<div><p>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.</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.