2009-04-21 7 views
2

Wir erstellen eine App, die Module verwendet, die dynamisch in das Haupt-SWF geladen werden. Das Problem, auf das wir stoßen, ist, dass wir die Module, die sich auf einem Testserver befinden, nicht laden können, wenn wir die Hauptanwendung lokal debuggen. Der Fehler, den wir bekommen, ist "SWF ist kein ladbares Modul".SWF ist kein ladbares Modul

Ich sah dies nach und fand heraus, dass wir eine Crossdomain-Datei auf dem Server benötigen, die die Berechtigung zum Laden der Module von externen Standorten gewährt. Also haben wir eine einfache crossdomain-Datei erstellt und diese auf den Server gestellt, aber das scheint nicht zu helfen.

Hier ist die domänenübergreifende Datei:

<cross-domain-policy> 
    <allow-access-from domain="*"/> 
</cross-domain-policy> 

Wir sind das Modul über die Module Klasse und alle Standardeinstellungen, keine benutzerdefinierte Anwendungsdomäne geladen usw. Wenn wir die Haupt-SWF auf die wir laden können Server bereitstellen zu die Module ohne Probleme.

Irgendwelche Hinweise? Sind in der crossdomain-Datei möglicherweise einige Einstellungen nicht vorhanden?

Update: Es scheint, dass das externe Modul erfolgreich geladen wurde (ich kann in meinem HTTP-Sniffer überprüfen) aber nicht initialisiert werden, wenn in der Haupt-App geladen. Der Fehler ist immer noch „SWF ist kein ladbares Modul)

Antwort

3

Hier ist eine vorgeschlagene soultion von Adobe JIRA: http://bugs.adobe.com/jira/browse/SDK-15393

+0

Danke. Die vorgeschlagene Problemumgehung hat den Zweck erfüllt. –

+0

Dito für mich. Oy vey, was für eine Hölle Workaround ... –

0

sieht ähnlich aus wie meine Cross-Domain-

<?xml version="1.0"?> 
<!DOCTYPE cross-domain-policy 
    SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> 
<cross-domain-policy> 
    <allow-access-from domain="*" /> 
</cross-domain-policy> 

, die auf Ihrem lokalen Server root ist, richtig?

Haben Sie Ihre Verzeichnisberechtigungen überprüft?

+0

Die domänenübergreif ist im Root-Verzeichnis der Tomcat-Installation und ich kann dies überprüfen, um es durch das Surfen. Das Problem scheint lokal zu sein, siehe mein Update. –

1

Ich glaube, Adobe versucht auf die Cross-Domain-Datei auf Port 843 zuzugreifen und wenn es die Datei an diesem Port nicht verbinden/finden kann, versucht es den Port, mit dem Sie versuchen, eine Verbindung herzustellen (wahrscheinlich 80, wenn es http ist) sicher, aber Sie möchten vielleicht überprüfen, um sicherzustellen, dass Ihr ser ver ermöglicht den Zugriff auf die Datei.

Erwähnenswert ist auch, dass Sie vollen Zugriff auf das Verzeichnis, in dem sich Ihre lokale SWF-Anwendung befindet, erlauben sollten. Tun Sie dies mit dem Manager Adobe Einstellungen: http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html

Als Randbemerkung, ich glaube, die Einstellungen Manager eines der schlimmsten UI atrocoties im Flash-Öko-System ist. Nur die Tatsache, dass sie in einem Text unter dem Manager klären müssen, dass es tatsächlich kein Screenshot ist, nimmt wirklich den Kuchen.

+0

lol, einverstanden. Ich habe diesen Link so vielen Mitarbeitern geschickt, dass sie zurückkommen und sagen: "Okay, wie komme ich dazu?" – nerdabilly

1

Ich stimme zu, dass es sich um ein Problem zwischen lokalen SWFs und Remote-SWFs handeln kann. Versuchen Sie, Ihre lokale Datei auf einen Server hochzuladen (auf jeden Server, auf den Sie Zugriff haben), oder versuchen Sie, bei Verwendung eines lokalen Apache oder IIS auf diese SWF zuzugreifen, indem Sie http://localhost/ verwenden. Wenn das funktioniert, wissen wir, dass das Problem darin besteht, zwischen einer lokalen Datei und einer Remote-Datei zu wechseln. Wenn dies nicht der Fall ist, liegt das Problem entweder bei crossdomain.xml oder in Ihrem Code, was weniger wahrscheinlich ist, aber wir sollten es noch nicht ausschließen. Wenn Sie feststellen, dass das Problem mit der Verwendung einer lokalen SWF ist, dann in den Settings Manager den lokalen Ordner hinzufügen (siehe Mackes post)