THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
There are several solutions for you. Your component may implement IComponentResolver itself and resolve the child component. The TransparentWebMarkupContainer implementation may serve as an example.
The main reason why we removed MarkupContainer.isTransparentResolver() has been the magic necessary in Wicket's core and the number of issues/questions, where we identified isTransparentResolver() as the root cause. It all boils down to that with isTransparentResolver() the markup and component hierarchies get out of sync.
Noteable difference: different than MarkupContainer.isTransparentResolver() where the component id wasn't needed in the path (transparent), with IComponentResolver it must be included. Imagine you used to have a transparent container such as <body wicket:id="myBody">, where you were able to access a label from the Page just by "myLabel". In 1.5. you must use "myBody:myLabel".
IComponentResolver.
...
resolve API has changed
Until now, with IComponentResolver.resolve() it was your responsibility to render the component.
Another solution might be to subclass MarkupContainer.add() like discussed in WICKET-3045.
The main reason why we removed MarkupContainer.isTransparentResolver() has been the magic necessary in Wicket's core and the number of issues/questions, where we identified isTransparentResolver() as the root cause. It all boils down to that with isTransparentResolver() the markup and component hierarchies get out of sync.
IComponentResolver.resolve API has changed
Until now, with IComponentResolver.resolve() it was your responsibility to render the component. You returned true, if the component was found and rendered. That was because we had different means to render the component and wicket itself was not able to judge which one to use. That has changed and thus we were able to change the IComponentResolver.resolve API. With the revised API, you simply return the resolved component and wicket core knows what to do with it. It made Wicket's internal code simpler and hopefully yours as well.
...
Please see http://code.google.com/p/xebia-france/wiki/XForwardedFilter
which has been used as blueprint, though we are not using a ServletFilter. It's more tightly integrated to benefit from Wicket's core functionalities. See XForwardedRequestWrapperFactory and XForwardedRequestWrapper. The most convinient place to add them is via subclassing WebApplication.newWebRequest() in your own Application object.
(M5) Clarified if and when a xml decl gets added to the response
In case the markup file contains an xml decl such as <?xml version="1.0" encoding="utf-8" ?>, it'll only be used for properly reading the markup. It'll never be used for the response and it's presence or absence will no longer determine whether an xml decl gets added to the response or.
The response encoding is determined via Application.getRequestSettings().getResponseRequestEncoding() and applies for all your pages.
WebPage.renderXmlDecl(response) and WebApplication.renderXmlDecl(response) have been introduced to control the xml decl contribution. The behavior can be changed per Page or for your whole application. It can generally be enabled, disabled or determined via a rule. The rule currently is simple: if the page mime-type is application/xhtml+xml and the HTTP_ACCEPT header allows for the same, than insert the xml decl.
List of renamed classes and methods
...