On 29/07/2010 01:45, Ivan wrote:
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I have
checked it.
---
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext !=
Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?
2010/7/29 Mark Thomas ma...@apache.org
On 29/07/2010 01:45, Ivan wrote:
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
have
checked it.
---
public
On 29/07/2010 09:08, Ivan wrote:
Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?
Not sure what you mean. I don't see any issues with the spec. I do think
the implementation does something that is guaranteed to never succeed.
The
The below description from the spec says that resources inside the
META-INF/resources directory of JAR files might be consider only if the
container has unpacked them.
Since the getRealPath is used to return a virtual path, when will the
unpackaged location of resources directory be considered ?
On 28/07/2010 03:12, Ivan wrote:
Yes, Caldarale, I do agree that in the spec, there is no word about whether
the file should exist (or I miss something anywhere ?), and the spec is
always ambigurous :-)
As I said in my last post, what makes me feel confusing is that, with
current
Thanks, if possible, could you please show me where it is ? I am really
interested in those details :-)
2010/7/28 Mark Thomas ma...@apache.org
On 28/07/2010 03:12, Ivan wrote:
Yes, Caldarale, I do agree that in the spec, there is no word about
whether
the file should exist (or I miss
On 28/07/2010 14:11, Ivan wrote:
Thanks, if possible, could you please show me where it is ? I am really
interested in those details :-)
BaseDirContext
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For
Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I have
checked it.
---
public String getRealPath(String name) {
if (!aliases.isEmpty()) {
AliasResult result = findAlias(name);
if (result.dirContext != null) {
return
On 26/07/2010 03:20, Ivan wrote:
Hi,
Seems that the doGetRealPath method in the FileDirContext returns the
path directly without checking the target file or folder exists, so is it
expected or file checking is required ?
I don't see anything in the Servlet specification that says that the
I copied some words from the spec, the the second paragraph, it says
something about resources in the META-INF/resources directory, if we do not
need to care about whether the real file exists, I think we could never go
into this situation, we might always have a path in the default context.
right
From: Ivan [mailto:xhh...@gmail.com]
Subject: Re: FileDirContext returns the path directly without checking
whether the target file really exists
I copied some words from the spec, the the second paragraph,
it says something about resources in the META-INF/resources
directory, if we do
the resources in
the META-INF/resources folder.
2010/7/28 Caldarale, Charles R chuck.caldar...@unisys.com
From: Ivan [mailto:xhh...@gmail.com]
Subject: Re: FileDirContext returns the path directly without checking
whether the target file really exists
I copied some words from the spec
Hi,
Seems that the doGetRealPath method in the FileDirContext returns the
path directly without checking the target file or folder exists, so is it
expected or file checking is required ?
---
@Override
protected String doGetRealPath(String path) {
File file = new
13 matches
Mail list logo
