You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Caldarale, Charles R" <Ch...@unisys.com> on 2010/07/28 03:59:12 UTC

RE: FileDirContext returns the path directly without checking whether the target file really exists

> From: Ivan [mailto:xhhsld@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 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 ?

No.  The resource may or may not exist completely independently of whether or not the webapp has some location in the file system; you're confusing the situations.  One can use getRealPath() to determine the path for a resource the webapp wants to /create/, not just one the webapp wants to read.  If you want to see if the path returned points to an existing file, there are ample APIs in the JRE to let you do so.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Ivan <xh...@gmail.com>.
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 ? Only when the war
package is not unpacked, but the META-INF/resources directory are extracted
?
Thanks !
--->
Resources inside the META-INF/resources directory of JAR file must be
considered only if the container has unpacked them from their containing JAR
file
when a call to getRealPath() is made, and in this case MUST return the
unpacked
location.
<---

2010/7/29 Mark Thomas <ma...@apache.org>

> 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 resource JARs never get expanded so getRealPath() will always return
> null - there is no point checking.
>
> Mark
>
> >
> > 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 String getRealPath(String name) {
> >>>         if (!aliases.isEmpty()) {
> >>>             AliasResult result = findAlias(name);
> >>>             if (result.dirContext != null) {
> >>>                 return
> result.dirContext.doGetRealPath(result.aliasName);
> >>>             }
> >>>         }
> >>>
> >>>         // Next do a standard getRealPath()
> >>>         String path = doGetRealPath(name); ------> I think this
> >> invocation
> >>> will never return null in the FileDirContext implementation, right ? So
> >> does
> >>> it mean that if FileDirContext is used, no need to consider the
> resources
> >> in
> >>> the META-INF/resources embed in the jar files.
> >>
> >> Correct. I think the check of META-INF/resourcs below could be removed.
> >>
> >> Mark
> >>
> >>>
> >>>         if (path != null)
> >>>             return path;
> >>>
> >>>         // Check the alternate locations
> >>>         for (DirContext altDirContext : altDirContexts) {
> >>>             if (altDirContext instanceof BaseDirContext){
> >>>                 path = ((BaseDirContext) altDirContext).getRealPath(
> >>>                         "META-INF/resources/" + name);
> >>>                 if (path != null)
> >>>                     return path;
> >>>             }
> >>>         }
> >>>
> >>>         // Really not found
> >>>         return null;
> >>>     }
> >>> <---
> >>>
> >>> 2010/7/29 Mark Thomas <ma...@apache.org>
> >>>
> >>>> 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-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: users-help@tomcat.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Mark Thomas <ma...@apache.org>.
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 resource JARs never get expanded so getRealPath() will always return
null - there is no point checking.

Mark

> 
> 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 String getRealPath(String name) {
>>>         if (!aliases.isEmpty()) {
>>>             AliasResult result = findAlias(name);
>>>             if (result.dirContext != null) {
>>>                 return result.dirContext.doGetRealPath(result.aliasName);
>>>             }
>>>         }
>>>
>>>         // Next do a standard getRealPath()
>>>         String path = doGetRealPath(name); ------> I think this
>> invocation
>>> will never return null in the FileDirContext implementation, right ? So
>> does
>>> it mean that if FileDirContext is used, no need to consider the resources
>> in
>>> the META-INF/resources embed in the jar files.
>>
>> Correct. I think the check of META-INF/resourcs below could be removed.
>>
>> Mark
>>
>>>
>>>         if (path != null)
>>>             return path;
>>>
>>>         // Check the alternate locations
>>>         for (DirContext altDirContext : altDirContexts) {
>>>             if (altDirContext instanceof BaseDirContext){
>>>                 path = ((BaseDirContext) altDirContext).getRealPath(
>>>                         "META-INF/resources/" + name);
>>>                 if (path != null)
>>>                     return path;
>>>             }
>>>         }
>>>
>>>         // Really not found
>>>         return null;
>>>     }
>>> <---
>>>
>>> 2010/7/29 Mark Thomas <ma...@apache.org>
>>>
>>>> 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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Ivan <xh...@gmail.com>.
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 String getRealPath(String name) {
> >         if (!aliases.isEmpty()) {
> >             AliasResult result = findAlias(name);
> >             if (result.dirContext != null) {
> >                 return result.dirContext.doGetRealPath(result.aliasName);
> >             }
> >         }
> >
> >         // Next do a standard getRealPath()
> >         String path = doGetRealPath(name); ------> I think this
> invocation
> > will never return null in the FileDirContext implementation, right ? So
> does
> > it mean that if FileDirContext is used, no need to consider the resources
> in
> > the META-INF/resources embed in the jar files.
>
> Correct. I think the check of META-INF/resourcs below could be removed.
>
> Mark
>
> >
> >         if (path != null)
> >             return path;
> >
> >         // Check the alternate locations
> >         for (DirContext altDirContext : altDirContexts) {
> >             if (altDirContext instanceof BaseDirContext){
> >                 path = ((BaseDirContext) altDirContext).getRealPath(
> >                         "META-INF/resources/" + name);
> >                 if (path != null)
> >                     return path;
> >             }
> >         }
> >
> >         // Really not found
> >         return null;
> >     }
> > <---
> >
> > 2010/7/29 Mark Thomas <ma...@apache.org>
> >
> >> 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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by 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 String getRealPath(String name) {
>         if (!aliases.isEmpty()) {
>             AliasResult result = findAlias(name);
>             if (result.dirContext != null) {
>                 return result.dirContext.doGetRealPath(result.aliasName);
>             }
>         }
> 
>         // Next do a standard getRealPath()
>         String path = doGetRealPath(name); ------> I think this invocation
> will never return null in the FileDirContext implementation, right ? So does
> it mean that if FileDirContext is used, no need to consider the resources in
> the META-INF/resources embed in the jar files.

Correct. I think the check of META-INF/resourcs below could be removed.

Mark

> 
>         if (path != null)
>             return path;
> 
>         // Check the alternate locations
>         for (DirContext altDirContext : altDirContexts) {
>             if (altDirContext instanceof BaseDirContext){
>                 path = ((BaseDirContext) altDirContext).getRealPath(
>                         "META-INF/resources/" + name);
>                 if (path != null)
>                     return path;
>             }
>         }
> 
>         // Really not found
>         return null;
>     }
> <---
> 
> 2010/7/29 Mark Thomas <ma...@apache.org>
> 
>> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Ivan <xh...@gmail.com>.
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 result.dirContext.doGetRealPath(result.aliasName);
            }
        }

        // Next do a standard getRealPath()
        String path = doGetRealPath(name); ------> I think this invocation
will never return null in the FileDirContext implementation, right ? So does
it mean that if FileDirContext is used, no need to consider the resources in
the META-INF/resources embed in the jar files.

        if (path != null)
            return path;

        // Check the alternate locations
        for (DirContext altDirContext : altDirContexts) {
            if (altDirContext instanceof BaseDirContext){
                path = ((BaseDirContext) altDirContext).getRealPath(
                        "META-INF/resources/" + name);
                if (path != null)
                    return path;
            }
        }

        // Really not found
        return null;
    }
<---

2010/7/29 Mark Thomas <ma...@apache.org>

> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Ivan <xh...@gmail.com>.
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 something anywhere ?), and the spec is
> > always ambigurous :-)
> > As I said in my last post, what makes me feel confusing is that, with
> > current implementation, we never have chance to consider the resources in
> > the META-INF/resources folder.
>
> That has already been taken care of but the time the code reaches this
> point.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Ivan

Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by 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 something anywhere ?), and the spec is
> always ambigurous :-)
> As I said in my last post, what makes me feel confusing is that, with
> current implementation, we never have chance to consider the resources in
> the META-INF/resources folder.

That has already been taken care of but the time the code reaches this
point.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: FileDirContext returns the path directly without checking whether the target file really exists

Posted by Ivan <xh...@gmail.com>.
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 implementation, we never have chance to consider the resources in
the META-INF/resources folder.

2010/7/28 Caldarale, Charles R <Ch...@unisys.com>

> > From: Ivan [mailto:xhhsld@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 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 ?
>
> No.  The resource may or may not exist completely independently of whether
> or not the webapp has some location in the file system; you're confusing the
> situations.  One can use getRealPath() to determine the path for a resource
> the webapp wants to /create/, not just one the webapp wants to read.  If you
> want to see if the path returned points to an existing file, there are ample
> APIs in the JRE to let you do so.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Ivan