TilesConfigurer not safe to use in multiple DispatcherServlet definitions [SPR-11587]

[spring-projects-issues]

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: #1355

Attachments:

• playground.tar.bz2 (7.13 kB)

[spring-projects-issues]

Torsten Krah commented

Example project.

[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.

[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

[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.

[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

[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.

[tkrah]

@jhoeller Any news here?

[rstoyanchev]

Closing since Tiles support has been dropped for 6.0 with #27423.