wake-up-neo.net

Mit Java 7 Update 45 werden die Systemeigenschaften nicht mehr vom JNLP-Tag "Property" festgelegt.

Wir führen die Anwendung von der beigefügten JNLP aus. Auf der Java-Konsole haben wir die Systemeigenschaften mit D ausgegeben. Die Eigenschaften unserer JNLP-Dateien werden nicht mehr festgelegt. Dies ist die erste Java-Version, mit der wir solche Probleme bekommen. Bis einschließlich 7 Update 40 hat alles gut funktioniert.

Wir haben alle Krüge signiert, aber in ihren Manifesten gibt es keine Sicherheitsmerkmale.

<?xml version="1.0" encoding="UTF-8"?>

<jnlp spec="1.0+" codebase="http://10.0.10.230/webstart/app" href="desktop.jnlp">
<information>
<title>MyApp Desktop</title>
<vendor>MyApp GmbH</vendor>
<homepage href="http://www.myres-edv.de"/>
<description>MyApp Desktop</description>
<offline-allowed/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.5+" initial-heap-size="512M" max-heap-size="1024M" javaws-vm-args="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8200"/> 
 <property name="org.omg.CORBA.ORBInitialHost" value="10.0.10.230"/>             
 <property name="org.omg.CORBA.ORBServerHost" value="10.0.10.230" />
 <property name="Sun.net.spi.nameservice.provider.1" value="dns,Sun" />
 <property name="MyApp.baktswritedos" value="true"/>
 <property name="MyApp.nocomm" value="true"/>
 <property name="MyApp.la.erfassungdos" value="true"/>
 <property name="com.Sun.corba.ee.transport.ORBTCPConnectTimeouts" value="500:30000:40:30000" />
 <property name="deployment.trace.level" value="all" /> 
 <jar href="myresjar/ejb/myres/myres_ejb_client.jar" main="true" download="eager"/>
 <jar href="myresjar/ejb/myres/myres_ejb.jar" download="eager"/>
 <extension name="jars" href="commonejbjars.jnlp"/>
 <extension name="jars" href="jr.jnlp"/>
 <extension name="jars" href="commonjars.jnlp"/>
 <extension name="jars" href="commonjh.jnlp"/>
 <nativelib href="myresjar/ejb/myres/myres_dll.jar"/>
</resources>
<resources os="Windows">
    <nativelib href="myresjar/myres/native-dlls.jar" download="eager"/>
</resources>
<application-desc main-class="de.myapp.gui.desktop.mainframe.DesktopMainFrame">
   <argument>-serverIP=10.0.0.230</argument> 
   <argument>-initNewDayAction=true</argument> 
</application-desc>
</jnlp>    
25
user2885888

Das gleiche Problem ist mit Java 7 Update 45 (1.7.0_45) aufgetreten. Die JNLP Spec gab einen Hinweis für eine Problemumgehung:

In der jnlp-Datei festgelegte Eigenschaften werden normalerweise von Java Web Start festgelegt, nachdem VM gestartet wurde, aber bevor die Anwendung aufgerufen wird. Einige Eigenschaften werden als "sichere" Eigenschaften betrachtet und können in der Java-Aufrufbefehlszeile als Argumente -Dkey = value übergeben werden.

Die folgenden Eigenschaften sowie Eigenschaften, die mit "jawaws" beginnen. oder "jnlp." werden als "sicher" betrachtet und auf folgende Weise an die VM übergeben: ...

Während "unsichere" Eigenschaften nicht mehr funktionierten, stellten wir fest, dass "sichere" Eigenschaften immer noch korrekt festgelegt wurden . Möglicherweise wurde der Mechanismus, der Eigenschaften nach dem Start von VM festlegt, aber bevor die Anwendung aufgerufen wird, damit beschädigt Java-Update oder vielleicht war dies eine beabsichtigte, aber nicht dokumentierte Änderung. 

Die Problemumgehung hängt jetzt von der Art der Systemeigenschaften ab:

Bei Systemeigenschaften, die sich auf das Verhalten von Java oder auf Bibliotheken auswirken, haben wir unseren Code so geändert, dass er beim Start der Anwendung System.setProperty () aufruft, anstatt sie im JNLP festzulegen.

Für Eigenschaften, die wir zum Konfigurieren der Anwendung aus der JNLP-Datei verwenden, haben wir jnlp hinzugefügt. Präfix, damit sie wieder korrekt übergeben werden.

<property name="myconfig" value="DE" />

zu

<property name="jnlp.myconfig" value="DE" />

Edit: Laut OpenJDK-Fehler JDK-8023821 war die Änderung beabsichtigt:

Ab 7u45 muss der Startdeskriptor (JNLP-Datei) signiert werden, um unsichere Systemeigenschaften festzulegen. Es wird also ein Verhalten in 7u45 erwartet ... (von einem Kommentar)

Anweisungen zum Signieren eines JNLP .

32
Michael Paesold

Wir sind ein bisschen schlecht von dieser Ausgabe gekommen. Am Ende haben wir die JNLP-Datei in das signierte Glas eingeschlossen. Dies stellte uns jedoch vor einige knifflige Build-Probleme, da wir zuvor einen Satz von JARS erstellt hatten und mehrere JNLP-Dateien für die Unterstützung verschiedener Umgebungen (QA, Produktion, Demo) verwendeten usw.), Weitergabe der Umgebungsdetails an die App über eine Systemeigenschaft. Wir haben versucht, eine JNLP-Vorlagendatei zu verwenden, wie hier beschrieben, http://docs.Oracle.com/javase/7/docs/technotes/guides/jweb/security/signedJNLP.html , aber wir haben es behalten Fehler beim Überprüfen der JNLP-Datei erhalten und aus Zeitgründen aufgegeben werden. Es ist möglich, dass wir nur etwas falsch gemacht haben, aber durch die Fehlermeldungen wurde überhaupt nicht klar, welcher Teil der JNLP-Datei nicht mit der Vorlage übereinstimmt. Darüber hinaus gibt es diesen etwas hilfreichen Hinweis im obigen Link: "Elemente oder Attribute, die die Sicherheit beeinträchtigen können, werden von dieser Funktion gesperrt." Ich konnte keine dokumentierten Beispiele für solche Elemente oder Attribute finden.

4
PRS

Hatte das gleiche Problem und löste es durch das Signieren der JNLP-Datei. Ihr Haupt-Jar sollte eine Kopie der jnlp-Datei enthalten, die in APPLICATION.JNLP umbenannt und im Ordner JNLP-INF abgelegt wird (der Name des Ordners und die jnlp-Datei müssen Großbuchstaben sein).

2
user2886002

Ich setze als:

<jnlp>
...
    <application-desc main-class="Main">
        <argument>param1=value1</argument>
    </application-desc>
</jnlp>

Ps. Denken Sie nur daran, dass die Übergabe von Werten mithilfe des Tags Sie Anwendungsparameter und nicht JVM-Parameter übergeben. Ihre Anwendung sollte diesen Parameter in Ihrem Methodenhauptbereich abfangen (String args []).

2
Sergey Nebezb

Ich habe gerade 2 Tage damit verbracht, dieses Problem zu beheben und zu versuchen, Gläser und andere Dateien zu signieren ... und dann fand ich die Lösung, die sehr einfach zu sein scheint und gut funktioniert:

Ich * lege eine Jndi.properties-Datei mit folgendem Inhalt in meinen JRE-Home-Director * y (jre7/lib):

Java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
Java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
Java.naming.provider.url=jnp://localhost:1099

Ich hatte dieses Problem beim Aktualisieren von Java 1.6 auf Java 1.7 (51) ...

0
frasch333