TilesConfigurer and DefaultRendererViewResolver
Oh yes, I missed that one. I've found it easy enough to instanciate a new DefinitionRenderer directly in applicationContext.xml (with AOP for profiling).
BTW, do you think we should make TilesContainer implement Renderer directly?
One package is fine with me. From a spring point of view, this is just one component among many others.
But how would DispatchRequest in turn become a hidden internal or removed?
I failed to make my case in that discussion you refer to, and I don't want to reopen it here. DispatchRequest is needed for backwards-compatible behaviour, and an improvement over tiles-2.2. I still hope that sooner or later we will agree on what's needed for the future; in the mean time we have no clear plan for DispatchRequest, and I see it as touchy.
Do we agree that SpringRequest is (slightly) more useful if it extends DefaultRequestWrapper instead of DispatchRequestWrapper? Right now we integrate only with spring MVC, but I hope things like spring-mail could work with tiles-request in the future.
Unwrapping is not perfect either, since we're loosing some functionality (like the extra scopes added when wrapping), but that's basically what DispatchRenderer will be doing when relying on servlet/portlet anyway.