Torsten Krah opened SPR-11587 and commented
Hi,
got some mysterious problem.
Just do a "gradle jettyRunWar" on the attached project and go to http://localhost:8080/web/view/ and http://localhost:8080/admin/view/ - it will render Apples and Tomatoes.
Stop the stuff and go to the web.xml and remove the comments from load-on-startup of the tomatoes servlet.
If you now go to http://localhost:8080/web/view/ you get
javax.servlet.ServletException: Could not resolve view with name 'admin-index' in servlet with name 'apples'
I don't know exactly what the error is - but in another project we got 3 DispatcherServlets in one web.xml which are all mapped to different URLs and each got its own Tiles definitions. Only one Servlet can found its mappings, the other Servlets fails to find their views.
It maybe related to SpringWildcardServletTilesApplicationContext which uses the ServletContext to store things (or the app key which is null) - but that only a guess, still searching the exact cause.
Affects: 4.0.2, 4.0.3, 4.0.4, 4.0.5, 4.0.6
Reference URL: https://github.com/spring-projects/spring-framework/pull/1355
Attachments: - playground.tar.bz2 (7.13 kB)
Comment From: spring-projects-issues
Torsten Krah commented
Example project.
Comment From: spring-projects-issues
Torsten Krah commented
Maybe its possible to use the DispatcherServletName as default containerKey http://tiles.apache.org/framework/tutorial/advanced/multiple-containers.html instead of null.
Comment From: spring-projects-issues
Juergen Hoeller commented
Indeed, it may be necessary to always qualify the container to use. In addition to overriding getContainerKey in our SpringTilesInitializer, we'd have to set the same key for the TilesContainer lookup in TilesView's afterPropertiesSet, and I suppose we'd also have to call TilesAccess.setCurrentContainer for every request before invoking the Tiles renderer in TilesView...
Juergen
Comment From: spring-projects-issues
Torsten Krah commented
If possible when this is going to be fixed - it would be nice to have most of those tiles integration classes and methods protected to be able to reuse the Spring Components to integrate Tiles but be able to overwrite some of them (currently most of them are private), if some customizing while integrating tiles and spring is needed. Currently you are forced to just overwrite mostly all classes and copy all the code while the goal is to just overwrite one method. Maybe this can be done with this ticket too.
Comment From: spring-projects-issues
Juergen Hoeller commented
Now is a fine time to pick this one up for 4.3! Concrete change proposals are very welcome, both for the container qualifier part and the method visibility part...
Juergen
Comment From: spring-projects-issues
Torsten Krah commented
Juergen Hoeller i did a first try for that one under:
https://github.com/tkrah/spring-framework/tree/SPR-11587
Should i include the visibility part there too or do two changesets - one for the issue itself and one for the visibility thing? Its not yet polished - would be nice to first discuss about the general approach if i am on the right track - guess its better to actually discuss that on the pull request, going to submit one.
Comment From: tkrah
@jhoeller Any news here?
Comment From: rstoyanchev
Closing since Tiles support has been dropped for 6.0 with #27423.