More on Windows/jetty

[Rod Widdowson]

(I hope that this only gets delivered only once, Outlook took a fit with my last mail to this list, my apologies.  I have applied
some fixes locally)

When I was getting the windows installer for Jetty9.4/IdP3.4 I discovered that to make progress I have to avoid forking jetty.
Last week I took an action item to investigate what the root causes were.

To that end I opened IDP-1326 to act as a log of all I found; it makes for interesting reading but it is full of needless details.

The key findings are:

1)  Forking inside jetty does not do anything sensible about inheriting the security state of the forking process.  This impacts if
you start from an elevated prompt (because the child runs unelevated).  Starting from a fully privileged account seems to do the
right thing.  This makes sense in terms of "If you didn't know to do something special this is the result you'd get".

2) Forking inside jetty selectively destroys the setting of (some) inherited variables.  This affects us because we want to set
idp.home and setting it to

	-Didp.home=C:/Program Files (x86)/Shibboleth/IdP
	
     Results in the forked process being given

	[7]: "-Didp.home=C:/Program\ Files\ (x86)/Shibboleth/IdP"

     Which doesn't end well when we try to open our configuration

3) If you set the property in the system environment you can get further.  But better be sure to avoid native directory delimiters
('\').  If you use them, then we fail in Spring 

	Caused by: java.io.FileNotFoundException: C:\Program Files (x86)\Shibboleth\IdP\system\conf\conditional:C:\Program Files
(x86)\Shibboleth\IdP\conf\admin\unlock-keys.xml (The filename, directory name, or volume label syntax is incorrect)

      I haven't bothered to chase up why this happens, but it doesn't surprise me.

The bottom line remains the same - do not fork on windows.  If you do fork,  do not expect to be able to pass anything sensible down
via environment variables.

I don't really feel like taking this any further.  I could dig to the bottom of (3) if people wanted and I suppose I might just
about be able to pull together a PR to fix (2) - or better still write something such that the output of --dry-run could be sensible
fed into procrun, which is their documented way to run jetty as a daemon.

Thoughts?

/Rod