All,
unfortunately I think there is one more moderate refactor needed before jetty-12 final... but probably not needed for a beta.
We have several context.xml files (examples, demos and documentation) that configure a context by using insertHandler on the context to insert a GzipHandler (or similar).
Whilst this still works for ee8/ee9, it does not work for ee10, as we wrap at the ServletContextHandler level, so any subsequent wrapping of the request/response is bypassed when we do a Request.as(request, ServletContextRequest.class);
I've had a few tries at working around this, primarily by introducing a Handler.wrap method, that looks for the container of the handler and inserts the wrapper above it. That way, the context itself would be wrapped by the GzipHandler, which works fine. But the problem is that at the point we execute a context.xml file, the contextHandler has not yet been added to the ContextHandlerCollection, thus it cannot be found by a search of the handler tree and we can't wrap it then.
We could perhaps modify the deployer so that it is happy for a context.xml file to return any type of Handler, so long as there is a ContextHandler within it. the xml would then configure the GzipHandler with the ContextHandler contained within it.
Another option is for the ServletHandler to "rebase" the API wrappers on the request/response it receives, so that any intervening wrapping is used. This is doable either as a very specific ee10 servlet mechanism, or even as a general Handler.Wrapper mechanism that signals if a request/response is wrapped so it can know it's outer wrapper.
However, for that to work efficiently, the EE10 SecurityHandler would need to no longer operate on API request/response but instead on core request/response. This is probably desirable anyway as it will give us core security. However, whilst we have core sessions, we don't have a standard way of accessing those, so we'd need to create some mechanism so that core security could see core sessions, even if those sessions are wrapped as API sessions. I think this is doable and probably a good idea anyway, regardless of the insertHandler issue.
So Lachlan, can you ponder a core security module - let's chat early next week (or tomorrow if I see you over here).
Jan, can we chat about a standard session access mechanism (maybe just some well known attributes that can be mapped to fields in API wrappers or left as attributes in core request).
Joakim, can you ponder the changes needed to the deployer to allow for non ContextHandler Handlers to be created for an App?
cheers
