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
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 r
Thanks, Mark.
So in other words, those descriptions in the spec for META-INF/resources
make no sense. right ?
2010/7/29 Mark Thomas
> On 29/07/2010 01:45, Ivan wrote:
> > Thanks, Mark, if you mean the method getRealPath in BaseDirContext, I
> have
> > checked it.
> >
> > --->
> > public String g
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.dirContex
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.dirCon
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, if possible, could you please show me where it is ? I am really
interested in those details :-)
2010/7/28 Mark Thomas
> 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 anywhe
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 implemen
the resources in
the META-INF/resources folder.
2010/7/28 Caldarale, Charles R
> > 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: 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/resource
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
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
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 File(getDo
13 matches
Mail list logo
