Moin.
Wir haben eine Applikation auf XULrunner Basis im Einsatz.
Bisher konnte man da in der chrome.manifest Datei ein 'entferntes' JAR mit Applikationslogik angeben. Das geht nun nicht mehr (Release Notes).
Weiss jemand ob ich im chrome.manifest Platzhalter verwenden kann?
Also in etwa so:
Wir haben eine Applikation auf XULrunner Basis im Einsatz.
Bisher konnte man da in der chrome.manifest Datei ein 'entferntes' JAR mit Applikationslogik angeben. Das geht nun nicht mehr (Release Notes).
Weiss jemand ob ich im chrome.manifest Platzhalter verwenden kann?
Also in etwa so:
content myapp jar:($ProfD)/myapp.jar!/content/
content myapp2 jar:($TEMP)/myapp2.jar!/content/
...
|
2,0k ● 7 |
1 Antworten
Nur damit es nicht offen hier stehen bleibt:
1) Platzhalter sind nicht möglich.
2) Runtime Änderungen an der chrome.manifest sind nicht möglich (Verzeichnisschutz).
Meine Lösung:
2) Im chrome.manifest statt jar:bla.jar!/content/ einen eigenen Handler nutzen mit own:id
1) Einen eigenen ProtocolHandler implementieren (own: abhandeln), der das JAR file lokal im User-Temp verzeichnis ablegt (bei jedem Start frisch, aber den Browser-Cache nutzend). Dann wird intern in diesem OwnProtocolHandler der JarProtocolHandler verwendet um die Daten aus dem gebufferten JAR liefert.
Da das JAR file dann lokal abgelegt ist greifen andere Sicherheitsmechanismen und alles ist ganz prima :)
1) Platzhalter sind nicht möglich.
2) Runtime Änderungen an der chrome.manifest sind nicht möglich (Verzeichnisschutz).
Meine Lösung:
2) Im chrome.manifest statt jar:bla.jar!/content/ einen eigenen Handler nutzen mit own:id
1) Einen eigenen ProtocolHandler implementieren (own: abhandeln), der das JAR file lokal im User-Temp verzeichnis ablegt (bei jedem Start frisch, aber den Browser-Cache nutzend). Dann wird intern in diesem OwnProtocolHandler der JarProtocolHandler verwendet um die Daten aus dem gebufferten JAR liefert.
Da das JAR file dann lokal abgelegt ist greifen andere Sicherheitsmechanismen und alles ist ganz prima :)
|
|
2,0k ● 7 |
