[BLOSSOM-16] BlossomDispatcherServlet fails to render when handlerPath is a subset of the requestURI Created: 20/Sep/10 Updated: 06/Dec/14 Resolved: 13/Dec/10 |
|
| Status: | Closed |
| Project: | Blossom |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.2 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Tobias Mattsson | Assignee: | Tobias Mattsson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
The overriding of pathinfo to match the correct handler is not enough. It works but not for all cases. Needs to be changed to properly setup pathinfo on the request object. Either by changed the request uri or simulate an include, depending on what spring supports. |
| Comments |
| Comment by Tobias Mattsson [ 23/Sep/10 ] |
|
Simulating forward and include requests is very fragile and will probably be very hard to get working properly in all containers. There's no 100% reliable solution and it will have to be tested in all containers to make sure that it works. Currently the only masquerading of the request that is performed is changing request.getServletPath(). This isnt enough. It should change all 5 path info getters. But getting that to play nicely with proper forwards is hard. Blossom doesn't simulate includes at all now. When rendering with blossom from inside an include its likely that Spring won't be able to resolve the controller that is to be executed and will instead use the last include requestUri. The solution will have to be to do real include() and forward() onto BlossomDispatcherServlet. But since the Magnolia filter chain doesn't handle includes it will have to be mapped on its own in web.xml. It must also not be initialized if magnolia starts in install/update -mode. Perhaps it might even need a filter chain of its own that initializes only when the install/update phase is over. Which is a rather large undertaking. This issue has resulted in discussions about have the magnolia filter chain handling include requests as well, this would be a far easier solution. |
| Comment by Tobias Mattsson [ 28/Sep/10 ] |
|
Attached a patch that has been tested and works in Tomcat 6.0.24 |
| Comment by Tobias Mattsson [ 26/Nov/10 ] |
|
New patch, the previous one had strange paths that made it troublesome to apply, and a binary of the patch applied. |
| Comment by Jan Haderka [ 06/Dec/14 ] |
|
Bulk close of old resolved issues. |