| Anonymous | Login | Signup for a new account | 10-24-2025 02:32 PDT |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0000281 | [Resin] | minor | always | 06-21-05 00:00 | 04-05-06 10:46 | ||||
| Reporter | user142 | View Status | public | ||||||
| Assigned To | |||||||||
| Priority | normal | Resolution | fixed | ||||||
| Status | closed | Product Version | |||||||
| Summary | 0000281: VFS Merge Path and getRealPath() bug | ||||||||
| Description |
RSN-316 Assuming webapps setup like so: <web-app id="/foo" document-directory="merge:(/a;/b)"/> <web-app id="/bar" document-directory="/c"/> With the following files: /a/a.txt /b/b.txt /c/c.txt Asking for: context.getContext("/foo").getRealPath("/a.txt") will return "/a/a.txt" as expected. Similarly: context.getContext("/foo").getRealPath("/b.txt") will return "/b/b.txt" as expected. However, asking for: context.getContext("/foo").getRealPath("/nosuchfile.txt") returns ".//nosuchfile.txt", which is definately not expected. If you ask for the same type of thing from a webapp that does not use the vfs merge path feature, like so: context.getContext("/bar").getRealPath("/nosuchfile.txt") you get "/c/nosuchfile.txt", which is what I would expect. The /foo webapp with the vfs merge path should behave similarly. While I realize there is ambiguity there, I think it would be more benign to simply pick a path from the merge list (any path really, though the first one would seem logical) instead of a completely arbitrary path. |
||||||||
| Additional Information | WinXP, JDK1.4.2_08 | ||||||||
| Attached Files | |||||||||
|
|
|||||||||
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
33 total queries executed. 26 unique queries executed. |