IHeaderResponse is used in HtmlHeaderContainer and AjaxRequesTarget for collecting header contributions to be streamed out first before the rest of the response.
In a portal environment the real response isn't under control of a portlet and writing to the html head section of a page isn't possible (yet, Portlet API 2.0 might add some support for it).
Furthermore, some portals might already provide some custom extensions which could allow porlets to contribute to the final page head section (Jetspeed-2 for instance does).
To allow intercepting HeaderResponse writing, I'm extending IHeaderResponse with a close() and isClosed() methods so a plugged in HeaderResponse implementation will be able to know when the response should be flushed.
Furthermore, I'm moving the getResponse() method up to HeaderResponse (final) and delegate it to a new protected abstract getRealResponse() method.
Finally, the HtmlHeaderContainer will check the new RenderContext.getHeaderResponse() to see if a custom IHeaderResponse implementation should be used (the default implementation will return null).
These changes all are non-intrusive and without any functional side-effect and could be applied to the Wicket core trunk without dependencies on the real portlet support.