Cómo pasar opciones de JVM desde bootRun

Estoy desarrollando aplicaciones web Spring simples que se comunican con el host remoto y me gustaría probarlas localmente detrás del proxy corporativo. Uso el complemento gradle “Spring Boot” y la pregunta es ¿cómo puedo especificar la configuración del proxy para JVM?

He intentado varias formas de hacerlo:

  1. gradle -Dhttp.proxyHost=XXXX -Dhttp.proxyPort=8080 bootRun
  2. export JAVA_OPTS="-Dhttp.proxyHost=XXXX -Dhttp.proxyPort=8080"
  3. export GRADLE_OPTS="-Dhttp.proxyHost=XXXX -Dhttp.proxyPort=8080"

Pero parece que ninguno de ellos funciona – “NoRouteToHostException” arroja el código de “red”. Además, he agregado un código adicional para depurar argumentos de inicio de JVM:

  RuntimeMXBean runtimeMxBean = ManagementFactory.getRuntimeMXBean(); List arguments = runtimeMxBean.getInputArguments(); for (String arg: arguments) System.out.println(arg); 

Y solo se imprimió un argumento: “-Dfile.encoding = UTF-8”.

Si configuro la propiedad del sistema en código:

  System.setProperty("http.proxyHost", "XXXX"); System.setProperty("http.proxyPort", "8080"); 

¡Todo funciona bien!

Respuesta original (usando Gradle 1.12 y Spring Boot 1.0.x):

La tarea bootRun del plugin Spring Boot gradle extiende la tarea gradle JavaExec. Mira esto

Eso significa que puede configurar el complemento para usar el proxy agregando:

 bootRun { jvmArgs = "-Dhttp.proxyHost=xxxxxx", "-Dhttp.proxyPort=xxxxxx" } 

a su archivo de comstackción.

Por supuesto, puede usar las systemProperties del systemProperties lugar de jvmArgs

Si desea agregar jvmArgs condicionalmente desde la línea de comando, puede hacer lo siguiente:

 bootRun { if ( project.hasProperty('jvmArgs') ) { jvmArgs project.jvmArgs.split('\\s+') } } gradle bootRun -PjvmArgs="-Dwhatever1=value1 -Dwhatever2=value2" 

Respuesta actualizada:

Después de probar mi solución anterior usando Spring Boot 1.2.6.RELEASE y Gradle 2.7 observé que no estaba funcionando ya que algunos de los comentarios mencionan. Sin embargo, se pueden hacer algunos ajustes menores para recuperar el estado de trabajo.

El nuevo código es:

 bootRun { jvmArgs = ["-Dhttp.proxyHost=xxxxxx", "-Dhttp.proxyPort=xxxxxx"] } 

para argumentos codificados, y

 bootRun { if ( project.hasProperty('jvmArgs') ) { jvmArgs = (project.jvmArgs.split("\\s+") as List) } } 

para los argumentos proporcionados desde la línea de comando

 bootRun { // support passing -Dsystem.property=value to bootRun task systemProperties = System.properties } 

Esto debería pasar todas las opciones de JVM a la aplicación iniciada a través de bootRun .

En el script de comstackción gradle, defina las propiedades del sistema para ejecutar la tarea.

 //to provide the properties while running the application using spring-boot's run task run { systemProperties['property name'] = 'value' } 

y gradle run debería aceptar este valor.

O defina una propiedad de nivel de proyecto como se menciona en http://forums.gradle.org/gradle/topics/how_can_i_provide_command_line_args_to_application_started_with_gradle_run

@marvin, gracias por tu publicación fue muy útil.

Compartiendo cómo lo usé:

 test { // support passing -Dsystem.property=value to bootRun task systemProperties = System.properties } 

Tengo pruebas JUnit que quería omitir a menos que se utilizara una propiedad para incluir dichas pruebas. Usando JUnit Assume para incluir las pruebas condicionalmente:

 //first line of test assumeThat(Boolean.parseBoolean(System.getProperty("deep.test.run","false"),true) 

Hacer esto con gradle requiere que la propiedad del sistema proporcionada en el momento de ejecutar la comstackción gradle, que se muestra aquí,

 gradle build -Ddeep.test.run=true 

de hecho pasó a las pruebas.

Espero que esto ayude a otros a probar este enfoque para ejecutar pruebas condicionalmente.

Parece funcionar:

 bootRun { systemProperties "property1": "value1", "property2": "value2" } 
 bootRun { args = ['myProgramArgument1', 'myProgramArgument2'] } 

El uso de jvmArgs puede causar problemas de inicio de JVM. Usar args le permite pasar los argumentos de su progtwig personalizado

Me metí en un problema similar, bootRun necesitaba algunos parámetros, pero no tenía ganas de modificar bootRun ya que quería mantener cierta flexibilidad y mantener el comportamiento estándar de arranque. Mi sugerencia es agregar algunas tareas personalizadas (digamos bootRunDev, bootRunProxy) que extienden bootRun, como se describe en el siguiente fragmento de código

 task bootRunPxy(type: org.springframework.boot.gradle.run.BootRunTask, dependsOn: 'build') { group = 'Application' doFirst() { main = project.mainClassName classpath = sourceSets.main.runtimeClasspath systemProperty 'http.proxyHost', 'xxxxx' systemProperty 'http.proxyPort', 'yyyyy' } } 

No tengo un entorno para ejercitar el script, pero utilicé este enfoque para pasar el perfil a la spring con la propiedad spring.profiles.active. Los créditos deberían ir a Karol Kaliński

    Intereting Posts