CHANGELOG.md | 6 6 + 0 - 0 !
project.clj | 2 1 + 1 - 0 !
src/puppetlabs/trapperkeeper/services/webserver/jetty9_config.clj | 1 1 + 0 - 0 !
src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj | 35 19 + 16 - 0 !
test/clj/puppetlabs/trapperkeeper/services/webserver/jetty9_default_config_test.clj | 13 8 + 5 - 0 !
test/clj/puppetlabs/trapperkeeper/services/webserver/jetty9_service_test.clj | 12 8 + 4 - 0 !
test/clj/puppetlabs/trapperkeeper/services/webserver/normalized_uri_helpers_test.clj | 6 3 + 3 - 0 !
7 files changed, 46 insertions(+), 29 deletions(-)

 [patch] (tk-369) update jetty dependency to 9.4.1

This commit updates jetty to 9.4.1, which requires several changes to
tests and the config and core namespaces. Here are a list of changes and
why they were made:

Code changes

* Manually start the request logger when set
  This change
    https://github.com/eclipse/jetty.project/commit/34a8da2ba26a806413f06ab18fdfad535de45cfa
  seems to have caused logging to no longer work without starting here.
  Starting after the server was started did not do the right thing.

* GzipHandler changes
  GzipHandler moved into a new package, into jetty-server from
  jetty-servlets and some of the setup methods changed, notably
  around excluding mime types.

* ProxyServlet changes
  Several methods in the ProxyServlet and AbstractProxyServlet were
  deprecated, so the methods being proxied also have been updated.

* Enable client redirects
  The http connection used for proxies began clearing all handlers in

src/puppetlabs/trapperkeeper/services/webserver/jetty9_service.clj | 3 0 + 3 - 0 !
1 file changed, 3 deletions(-)

 [patch] (server-2213) remove call to mbeancontainer/resetunique

In a0cb4247e7f99f79c67f08acd6bdae2ac5bf1f8e of Jetty the functionality
of resetUnique was folded into the default behavior of destroy, which we
already call in core/shutdown as part of our normal shutdown procedure.

java/com/puppetlabs/trapperkeeper/services/webserver/jetty9/utils/LifeCycleImplementingRequestLogImpl.java | 32 32 + 0 - 0 !
src/puppetlabs/trapperkeeper/services/webserver/jetty9_config.clj | 7 3 + 4 - 0 !
2 files changed, 35 insertions(+), 4 deletions(-)

 (tk-369) add lifecycleimplementingrequestlogimpl

As of Jetty 9.3, logback's RequestLogImpl will no longer auto-start
because it no longer implements Jetty's LifeCycle interface (because
Jetty refactored the RequestLog interfact to no longer extend the
LifeCycle interface). In order for our request logger to auto-start, we
extend logback's implementation and have it implement Jetty's LifeCycle
interface (which it already does).

java/com/puppetlabs/trapperkeeper/services/webserver/jetty9/utils/LifeCycleImplementingRequestLogImpl.java | 37 36 + 1 - 0 !
1 file changed, 36 insertions(+), 1 deletion(-)

 implement lifecycle methods missing from requestlogimpl

For some reason, our version of logback-access lacks some of Jetty 9.4's
LifeCycle methods. Implement them locally until we figure out what's
happening with the logback package.

src/puppetlabs/trapperkeeper/services/webserver/jetty9_core.clj | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 [patch] (maint) disable endpointidentification

Previously, Jetty disabled Endpoint Identification by default as it is a best
practice for most webservers who often cannot identify clients
connecting to it. However, in 9.4.15 Jetty changed this default to
"HTTPS", which is the best practice for _client_ SslContexts. This
caused serious breakages throughout the Jetty ecosystem and since 9.4.16
Jetty introduced static inner classes of SslContextFactory, named Server
and Client, to create the correct contexts for each type of consumer.

Unfortunately, because we subclass SslContextFactory with our own
InternalSslContextFactory that overrides CRL handling, using these static
inner class factories is problematic. Consequently, this patch takes the
approach of simply setting the Endpoint Identification Algorithm to null
as was previously the default (and necessary in most server
environments).

This will cause a warning of overriding a deprecated method during
compilation in newer Java versions and our approach to handling CRLs
will need to be reworked should we use this codebase as a basis for a
trapperkeeper-webserver-jetty10 project.

For more info see linked issues to the implementing PR here: