|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 281 | minor | always | 06-21-05 00:00 | 04-05-06 10:46 | |
|
|
|||||
| Reporter: | user142 | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | normal | OS Version: | |||
| Status: | closed | Product Version: | |||
| Product Build: | Resolution: | fixed | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.0.19 | ||
|
|
|||||
| 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. |
||||
| Steps To Reproduce: | |||||
| Additional Information: | WinXP, JDK1.4.2_08 | ||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||