New Windows Install may fail for want of a Jetty tmp dir
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
This needs research, but when I smoke tested the installer I got this failure:
2016-11-11 05:42:13 Commons Daemon procrun stderr initialized
java.nio.file.NoSuchFileException: C:\Program Files\Shibboleth\IdP\jetty-base\tmp\start_410949774866271910.properties
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
at java.nio.file.Files.newByteChannel(Unknown Source)
at java.nio.file.Files.createFile(Unknown Source)
at java.nio.file.TempFileHelper.create(Unknown Source)
at java.nio.file.TempFileHelper.createTempFile(Unknown Source)
at java.nio.file.Files.createTempFile(Unknown Source)
at org.eclipse.jetty.start.StartArgs.getMainArgs(StartArgs.java:596)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:204)
at org.eclipse.jetty.start.Main.start(Main.java:457)
at org.eclipse.jetty.start.Main.main(Main.java:75)
Creating the folder allows the service to start. This should be an easy fix but I need to get home to be able to fully test
Environment
None
Activity
Show:
Rod WiddowsonJanuary 6, 2017 at 11:54 AM
66ce060
Rod WiddowsonJanuary 6, 2017 at 8:22 AM
taking back
Tom ZellerJanuary 5, 2017 at 9:38 PM
I think that's fine, Rod. (by "that" I mean renaming tmp/.gitkeep to tmp/.donotdelete).
FWIW We manually exclude .gitkeep from the artifact via the maven-resources-plugin.
It seems that the packaging explicitly pulls the files called .gitkeep from the distro. As noted above this gives the window installer tummy troubles.
I could fix this in the installer - by forcing the directory to be made, but that seems like an abuse of the architecture.
My preferred solution is to rename the .gitkeep to .donotdelete. That way it will escape the packaging and turn up in the distro - this is no bad thing to my mind because end users might just care...
Thoughts?
Rod WiddowsonNovember 11, 2016 at 8:33 PM
(for 3.3.0.1 I can use the zip that I created, but I have a complete abhorence of building real products from non-real artefacts, so if we did that I'd want to check in the hand-adjusted zip file into the tag, just like I do the jetty and procrun zips)
This needs research, but when I smoke tested the installer I got this failure:
2016-11-11 05:42:13 Commons Daemon procrun stderr initialized java.nio.file.NoSuchFileException: C:\Program Files\Shibboleth\IdP\jetty-base\tmp\start_410949774866271910.properties at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source) at java.nio.file.Files.newByteChannel(Unknown Source) at java.nio.file.Files.createFile(Unknown Source) at java.nio.file.TempFileHelper.create(Unknown Source) at java.nio.file.TempFileHelper.createTempFile(Unknown Source) at java.nio.file.Files.createTempFile(Unknown Source) at org.eclipse.jetty.start.StartArgs.getMainArgs(StartArgs.java:596) at org.eclipse.jetty.start.Main.invokeMain(Main.java:204) at org.eclipse.jetty.start.Main.start(Main.java:457) at org.eclipse.jetty.start.Main.main(Main.java:75)Creating the folder allows the service to start. This should be an easy fix but I need to get home to be able to fully test