Started by making sure that the latest version still works.<\/p>\n
I already confirmed with Active State that you cannot upload a JAR directly, but have to unpack it so:<\/p>\n
from the working dir (same level as pom.xml)
\ncd .\/unpacked\/; unzip ..\/target\/unfamous-quotes-0.0.1-SNAPSHOT.jar; ls -al; cd ..
\nstackato push –path .\/unpacked\/<\/p>\n
But the application starts up on port 8080 which is not the port stackato wants it to run at and then it is killed and restarted and ..
\napplication.properties still has an entry about the server.port which I commented out and retried. But the server still started on
\nport 8080. So I made sure that the application.properties file was really updated which it was.<\/p>\n
In between tries I always removed application including the route with<\/p>\n
stackato delete unfamous-quotes\n<\/code><\/pre>\nNo luck. nothing helped.
\nI don’t understand though since I have an example that works and this app worked fine before I did some static file changes.<\/p>\n
No matter what I check or do stackato is not able to assign the right port and the server runs on 8080 until it is killed of.
\nOf course I could set the port like for my simple server test but that defeats the purpose.<\/p>\n
Besides, the exact same JAR works on Pivotal’s Cloud Foundation free tier run.pivotal.io with a simple push.<\/p>\n
cf push unfamous-quotes -p .\/target\/unfamous-quotes-0.0.1-SNAPSHOT.jar\n<\/code><\/pre>\nNext I tried another trick that I already learned in my experiments. I upload the jar with Eclipse (STS)
\nOr you can also push with CF, but then I would have to log out of run.pivotal.io – which I am using in parallel –
\nand into stackato, which also works. But unlike the stackato CLI the cf CLI does not allow multiple targets
\nand swithcing between them. So Eclispe it is.
\nThe push with Eclipse (or cf) will fail, too, but all it requires is a start of the app and the same jar works in stackato.<\/p>\n
Except that this does not resolve anything, the server still tstats on 127.0.0.0<\/p>\n
Setting the JAVA_OPTS environment variable has the same escaping problems as before, too.<\/p>\n
At this stage I am ready for one of my once in a month stress-release cigarettes.
\nThe stackato web UI does not do anything to calm me down, either. e.g. the page refresh is annoying.<\/p>\n
Even cf set-env<\/code> did not work I assume there is an incompatibility with the build back<\/p>\nsince the logs show this, which neither seems to work nor does it contain any of my environment variables:<\/p>\n
stackato[dea_ng.0]: Launching web process: $PWD\/.java-buildpack\/open_jdk\/bin\/java -cp $PWD\/.:$PWD\/.java-buildpack\/spring_auto_reconfiguration\/spring_auto_reconfiguration-0.8.9.jar -Djava.io.tmpdir=$TMPDIR -XX:MaxPermSize=64M -XX:OnOutOfMemoryError=$PWD\/.java-buildpack\/open_jdk\/bin\/killjava.sh -XX:PermSize=64M -Xms382293K -Xmx382293K -Xss995K org.springframework.boot.loader.JarLauncher --server.port=$PORT\n<\/code><\/pre>\nAnd I give up for now.<\/p>\n","protected":false},"excerpt":{"rendered":"
An unsuccessful test with my test app. Continue reading