Spring Cloud DataFlow Local-Server 1.2.2 fails to startup on Windows 10

Question

I'm attempting to follow the spring cloud data flow tutorial at this link http://cloud.spring.io/spring-cloud-dataflow/#quick-start.

When at Step 2, executing the following line

java -jar spring-cloud-dataflow-server-local-1.2.2.RELEASE.jar

Results in the following exception:

2017-07-01 16:21:00.218 WARN 3224 --- [ main] ationConfigEmbeddedWebApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskService' defined in class path resource [org/springframework/cloud/dataflow/server/config/features/TaskConfiguration.class]: Unsatisfied dependency expressed through method 'taskService' parameter 5; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'taskLauncher' defined in class path resource [org/springframework/cloud/deployer/spi/local/LocalDeployerAutoConfiguration.class]: Unsatisfied dependency expressed through method 'taskLauncher' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'spring.cloud.deployer.local-org.springframework.cloud.deployer.spi.local.LocalDeployerProperties': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.cloud.deployer.spi.local.LocalDeployerProperties]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: Java executable discovered via 'java.home' system property 'C:\Program Files\Java\jdk1.8.0_131\jre' is not executable or does not exist.

I think the key is the 'c:\program files\java\jdk1.8.0_131\jre' appears to be the wrong path to the java binaries. I would expect this to be the %JRE_HOME%\bin directory.

I wrote a small program to dump the system properties which produced the following:

java.home: C:\Program Files\Java\jdk1.8.0_131\jre

My JAVA_HOME, JRE_HOME, CLASSPATH and JDK_HOME environment variables are set as following

JAVA_HOME C:\Program Files\Java\jdk1.8.0_131
JDK_HOME %JAVA_HOME%
JRE_HOME %JAVA_HOME%\jre
CLASSPATH .;%JAVA_HOME%\lib;%JAVA_HOME%\jre\lib

The PATH variable is set to %JAVA_HOME%\bin

I have restarted my command prompt several times.

When I run the following command for the 1.1.4 version, the server starts up without error:

java -jar spring-cloud-dataflow-server-local-1.1.4.RELEASE.jar

I have tried to remove the JRE_HOME variable and have CLASSPATH set to .

Update: Adding output of dir c:\java.exe /s /b

c:\Program Files\Java\jdk1.8.0_131\bin\java.exe
c:\Program Files\Java\jdk1.8.0_131\jre\bin\java.exe
c:\Program Files\Java\jre1.8.0_131\bin\java.exe
c:\Program Files (x86)\Java\jre1.8.0_131\bin\java.exe
c:\ProgramData\Oracle\Java\javapath\java.exe
c:\ProgramData\Oracle\Java\javapath_target_260505593\java.exe
c:\Users\All Users\Oracle\Java\javapath\java.exe
c:\Users\All Users\Oracle\Java\javapath_target_260505593\java.exe

Answer 1

This is a bug: (impacts 1.2.2.RELEASE only and is fixed by 1.2.3.RELEASE)

https://github.com/spring-cloud/spring-cloud-deployer-local/issues/58

"Work around" solution is to goto the JRE path of java on your system and to run the following command

(note to other users to find your java path type echo %JAVA_HOME% in command prompt window, if there is a 'jdk' in the java home path make sure to alter it to 'jre' for the 'cd' command below. We need to navigate to the jre dir not jdk we also appended '\bin')

1. Navigate to the JRE's bin directory

cd C:\Program Files\Java\jre1.8.0_131\bin (notice: in the path "jre1.8" not jdk)

2. Make a copy of 'java.exe' called 'java' in this this same directory

copy java.exe java

Summary of Bug/Workaround:

the bug is basically... the developers were expecting the java executable to be called java and not java.exe as it is named on Windows OS. So the workaround is to make a copy of java.exe and name it java in that JRE's bin directory...

not sure how something like this makes it to production release though... :/

Answer 2

This bug is is fixed in the 1.2.3.RELEASE