С обновлением версии Java 7 45 свойства системы больше не установлены с тега JNLP "Свойство",

Мы запускаем приложение из присоединенного JNLP. На консоли Java мы выводим свойства системы с помощью D. Свойства из наших файлов JNLP больше не заданы. Это первая версия Java, с которой мы сталкиваемся с такими проблемами. Все работало нормально, вплоть до 7 Обновление 40.

У нас есть все банки, подписанные, но в их манифестах нет атрибутов безопасности.

<?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="#" onclick="location.href='http://www.myres-edv.de'; return false;"/>
<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>

Ответ 1

Мы столкнулись с той же проблемой с Java 7 Update 45 (1.7.0_45). JNLP Spec дал подсказку для рабочего процесса:

Свойства, установленные в файле jnlp, обычно устанавливаются Java Web Start после запуска виртуальной машины, но перед вызовом приложения. Некоторые свойства считаются "защищенными" свойствами и могут передаваться как аргументы -Dkey = value в командной строке java-вызова.

Следующие свойства, а также свойства, начинающиеся с "javaws". или "jnlp.", считаются "безопасными" и будут переданы VM таким образом:...

Пока "небезопасные" свойства перестали работать, мы поняли, что "защищенные" свойства будут по-прежнему корректно установлены. Возможно, механизм, который задает свойства после VM, запускается, но до того, как приложение вызывается, оно сломалось с этим обновлением Java, или, возможно, это было намеренное, но недокументированное изменение.

Работа вокруг теперь зависит от типа системных свойств:

Для системных свойств, которые влияют на поведение Java или библиотеки, мы изменили наш код, чтобы вызвать System.setProperty() при запуске приложения, а не устанавливать их в JNLP.

Для свойств, которые мы используем для настройки приложения из файла JNLP, мы добавили префикс jnlp., чтобы они были правильно переданы.

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

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

Изменить: Согласно OpenJDK Bug JDK-8023821, изменение было намеренным:

Начиная с дескриптора запуска 7u45 (файл JNLP), необходимо подписать, чтобы установить небезопасные системные свойства. Поэтому ожидается, что поведение в 7u45... (из комментария)

Инструкции для подписания JNLP.

Ответ 2

Мы плохо побили эту же проблему. В итоге мы отправились на путь включения файла JNLP в подписанную банку, но это показало нам некоторые сложные проблемы сборки, поскольку мы ранее построили один набор JARS и использовали несколько JNLP файлов для поддержки различных сред (QA, Production, Demo, и т.д.), передавая информацию о состоянии через приложение через системное свойство. Мы попытались использовать файл шаблона JNLP, как обсуждалось здесь, http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/signedJNLP.html, но мы продолжали получать ошибки, связанные с проверкой файла JNLP и отказались от временных ограничений. Возможно, мы просто делали что-то неправильно, но сообщения об ошибках не дали понять, какая часть файла JNLP не соответствует шаблону. Кроме того, в приведенной выше ссылке есть это несколько бесполезное замечание, в котором говорится: "Элементы или атрибуты, которые могут поставить под угрозу безопасность, будут заблокированы из этой функции". Я не мог найти документальных примеров таких элементов или атрибутов.

Ответ 3

Имел ту же проблему и решил ее, подписав файл jnlp. Ваша основная банка должна содержать копию файла jnlp, переименованного в APPLICATION.JNLP, и помещаться в папку JNLP-INF. (Имя папки и файл jnlp должны быть прописными)

Ответ 4

Я установил как:

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

Ps. Просто имейте в виду, что передача значений с использованием тега вы передаете параметры приложения, а не параметр JVM. Ваше приложение должно поймать этот параметр в главном методе (String args [])

Ответ 5

Просто потратил 2 дня, пытаясь исправить эту проблему, пытаясь подписать банки и другие файлы... и тогда я нашел решение, которое кажется очень простым и работает нормально:

I * поставьте jndi.properties файл со следующим содержимым в моем 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

У меня была эта проблема при обновлении с Java 1.6 до Java 1.7 (51)...