run - Con Java 7 Update 45, las propiedades del sistema ya no se establecerán en la etiqueta "Propiedad" de JNLP
jnlp run (5)
Acabo de pasar 2 días tratando de solucionar este problema, intentando firmar archivos jar y otros archivos ... y luego encontré la solución que parece ser muy simple y funciona bien:
* Puse un archivo jndi.properties con el siguiente contenido en mi 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
Tuve este problema al actualizar de Java 1.6 a Java 1.7 (51) ...
Ejecutamos la aplicación desde el JNLP adjunto. En la consola de Java, hemos generado las propiedades del sistema con D. Las propiedades de nuestros archivos JNLP ya no están configuradas. Esta es la primera versión de Java con la que tenemos este tipo de problemas. Todo funcionaba bien hasta e incluyendo 7 Update 40.
Tenemos todos los frascos firmados pero no hay atributos de seguridad en sus manifiestos.
<?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>
Experimentamos el mismo problema con Java 7 Update 45 (1.7.0_45). La especificación de JNLP dio una pista para una solución alternativa :
Las propiedades configuradas en el archivo jnlp normalmente serán configuradas por Java Web Start después de que se inicie la máquina virtual pero antes de que se invoque la aplicación. Algunas propiedades se consideran propiedades "seguras" y se pueden pasar como argumentos -Dkey = value en la línea de comandos de invocación de java.
Las siguientes propiedades, así como las propiedades que comienzan con "javaws". o "jnlp.", se consideran "seguros" y se pasarán a la VM de esta manera: ...
Mientras que las propiedades "inseguras" dejaron de funcionar, nos dimos cuenta de que las propiedades "seguras" todavía se establecerían correctamente. Tal vez el mecanismo que establece las propiedades después de que se inicia la VM, pero antes de invocar la aplicación, se rompa con esta actualización de Java, o tal vez fue un cambio intencional pero no documentado.
La solución ahora depende del tipo de propiedades del sistema:
Para las propiedades del sistema que afectan el comportamiento de Java o las bibliotecas, cambiamos nuestro código para llamar a System.setProperty () al inicio de la aplicación en lugar de configurarlas en el JNLP.
Para las propiedades que usamos para configurar la aplicación desde el archivo JNLP, agregamos el jnlp. Prefijo para que se pasen correctamente de nuevo.
<property name="myconfig" value="DE" />
a
<property name="jnlp.myconfig" value="DE" />
Edit: De acuerdo con OpenJDK Bug JDK-8023821 , el cambio fue intencional:
A partir de 7u45, el descriptor de lanzamiento (archivo JNLP) debe estar firmado para poder establecer propiedades inseguras del sistema. Así que es el comportamiento esperado en 7u45 ... (de un comentario)
Me puse como
<jnlp>
...
<application-desc main-class="Main">
<argument>param1=value1</argument>
</application-desc>
</jnlp>
PD. Solo tenga en cuenta que al pasar los valores usando la etiqueta, está pasando los parámetros de la aplicación y no el parámetro JVM. Su aplicación debe capturar este parámetro en su método main (String args [])
Nos pusimos un poco mal por este mismo problema. Terminamos yendo por el camino de incluir el archivo JNLP en el frasco firmado, pero eso nos presentó algunos problemas complicados de compilación, ya que anteriormente habíamos creado un conjunto de JARS y utilizamos varios archivos JNLP para admitir diferentes entornos (control de calidad, producción, demostración). , etc.), pasando los detalles del entorno a la aplicación a través de una propiedad del sistema. Intentamos utilizar un archivo de plantilla JNLP como se explica aquí, http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/signedJNLP.html , pero seguimos recibiendo errores relacionados con Verificando el archivo JNLP y renunciado debido a restricciones de tiempo. Es posible que estemos haciendo algo mal, pero los mensajes de error no dejaron en claro qué parte del archivo JNLP no coincide con la plantilla. Además, hay una nota un tanto inútil en el enlace anterior que dice: "Los elementos o atributos que pueden comprometer la seguridad se bloquearán de esta función". No pude encontrar ejemplos documentados de tales elementos o atributos.
Tuvo el mismo problema y lo resolvió firmando el archivo jnlp. Su archivo principal debe contener una copia del archivo jnlp cuyo nombre se ha cambiado como APPLICATION.JNLP y se encuentra en la carpeta JNLP-INF (el nombre de la carpeta y el archivo jnlp deben estar en mayúsculas)