Jetty deployment

[Rod Widdowson]

>Given conflicting defaults, we might consider providing backchannel
>support as a Jetty module, and the installer could prompt whether to
>enable|disable by copying an .ini file to the right place. Currently,
>in our "monolithic" (because we provide jetty.xml) Jetty
>configuration, toggling requires commenting|uncommenting XML, which is
>kind of a pain to automate, for example, the HTTP connector.

Thanks Tom, that sounds very helpful.

> I thought that modules followed the jetty-base-then-jetty-home
> configuration resolution rules, but I'd have to try it. 

Don't stress getting it done - I'll get to it if you don't.

And thanks to all for input.  

I'm feeling very much under time pressure so for now I'm going to keep it
simple and always configure backchannel.  However I'll make sure we don't
paint ourselves into the corner so that if I have time I can add optional
backchannel installs (MSI and non-MSI) for V1 (later otherwise)

I'm also going to try to pull off the "preserve the ini file, change the xml
files" paradigm. Whilst I respect that this restricts out capabilities I'd
argue that anyone who needs more from the container than we supply needs to
manage their own container.  The argument goes "If you [need to] know enough
to edit the xml files then you need to manage your container.  Thank you,
have a nice day."  All the QI install have people as far as tomcat goes was

- port selection (which I'm going to drop from the UI no one ever used it)
- back and front channel key-stores

And right now I don't want to go further.  If we have cycles before ship, I
am hearing the managing the back channel configuration at install time is
much more interesting.

/Rod