Anonymous | Login | Signup for a new account | 12-17-2024 08:43 PST |
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. |