You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Adam Jack <aj...@TrySybase.com> on 2003/05/01 05:55:12 UTC
[VFS] FileObject.exists (when HTTP) seems not to work as expected...
I am using commons VFS 1.0 and believe I am experiencing a problem with
FileObject.exists. The HttpClient I am running over is 2.0 alpha 2. I wonder
if somehow a change in the latter has caused the former to fail. Basically I
get "true" even when the object fails to exist. Anybody else seen this? Is
it me, or ought I attempt to log a bug report?
regards,
Adam
--
<http://www.try.sybase.com>
Experience Sybase Technology ...
[VFS] Is VFS in scarab? (was RE: [VFS] FileObject.exists (when HTTP) seems not to work as expected...)
Posted by Adam Jack <aj...@TrySybase.com>.
Is VFS really in scarab, or is that some Maven site default? I can't find a
role that allows me to report bugs on that module.
Also, I don't see it in bugzilla either.
Is this just me?
regards
Adam
-----Original Message-----
From: Adam Jack [mailto:ajack@trysybase.com]
Sent: Thursday, May 01, 2003 6:29 AM
To: 'Jakarta Commons Users List'
Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
expected...
> Basically I get "true" even when the object fails to exist. Anybody else
> seen this? Is it me, or ought I attempt to log a bug report?
I'm seeing the same problem. It's a bug.
Hmm, I went to try to log an issue, created an account, was told I didn't
have permission for the module, and then could not find a role to request
that seems appropriate for commons VFS.
http://scarab.werken.com/scarab/issues/
Any hints on how I log this?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Jack <aj...@TrySybase.com>.
I think I agree w/ Anthony in principle, although all I care about is an
HTTP UrlFileObject that works. I'd prefer not to have to have webdav (slide
is tough to gump) if I don't have to, but I am game to have http-client. I
don't have an opinion on how you structure your code hierarchy.
That said, first things first, I'd appreciate your committing Anthony's
patched UrlFileObject w/ the two new fixes (to exists and getLastModified)
and the "close URLConnection" leak removal. That'd be a big bonus for me.
Adam (Murdoch) thanks very much for stepping up to this, I am a heavy VFS
user for Krysalis Ruper, and I'd love to not have to build/ship my own
hacked library. So, thanks in advance.
regards
Adam
-----Original Message-----
From: Anthony Eden [mailto:me@anthonyeden.com]
Sent: Thursday, May 15, 2003 3:51 PM
To: Jakarta Commons Users List
Subject: Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Adam Murdoch wrote:
>On Fri, 16 May 2003 01:43 am, Adam Jack wrote:
>
>
>>I tell ya, I'd love to replace this code with HttpClient code, where we
>>could (1) set the UserAgent to be 'commons-vfs' (2) user HEAD and/or GET
>>(3) have "follow redirects work" (I found a bug in JDK java.net.URL where
>>it does not seem to follow relative redirects) and (4) only do (at most)
on
>>HEAD and one GET (if needed) per URL. [4 could be done with either
>>underlying code.]
>>
>>
>
>These are all good ideas. My plan for doing this was to extend the WebDAV
>provider to handle plain HTTP as well, since it already sits on top of
>HttpClient, and already does these things (uses OPTIONS instead of HEAD).
It
>just needs to be extended to handle non-dav resources.
>
I would rather have it work the other way around - the WebDAV provider
should extend the plain URL provider, or they should be kept separate.
I don't want to have to have WebDAV libraries if I am not using that
functionality.
Sincerely,
Anthony Eden
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Anthony Eden <me...@anthonyeden.com>.
Adam Murdoch wrote:
>On Fri, 16 May 2003 01:43 am, Adam Jack wrote:
>
>
>>I tell ya, I'd love to replace this code with HttpClient code, where we
>>could (1) set the UserAgent to be 'commons-vfs' (2) user HEAD and/or GET
>>(3) have "follow redirects work" (I found a bug in JDK java.net.URL where
>>it does not seem to follow relative redirects) and (4) only do (at most) on
>>HEAD and one GET (if needed) per URL. [4 could be done with either
>>underlying code.]
>>
>>
>
>These are all good ideas. My plan for doing this was to extend the WebDAV
>provider to handle plain HTTP as well, since it already sits on top of
>HttpClient, and already does these things (uses OPTIONS instead of HEAD). It
>just needs to be extended to handle non-dav resources.
>
I would rather have it work the other way around - the WebDAV provider
should extend the plain URL provider, or they should be kept separate.
I don't want to have to have WebDAV libraries if I am not using that
functionality.
Sincerely,
Anthony Eden
RE: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Jack <aj...@TrySybase.com>.
> You say this project is active, but I've not seen a VFS committer chime
in.
Apologies for that. I've been a little busier than I'd like recently.
> Any ideas how we entice one of them to work with us to help commit
your/our
> work?
Just keep hassling us :) I will get your changes applied this weekend.
Did this patch get applied? I've done updates from CVS, but don't see the
fix. Is it 'cos I overwrote it locally, or did it not occur?
regards
Adam
Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Murdoch <ad...@apache.org>.
On Fri, 16 May 2003 01:43 am, Adam Jack wrote:
> I tell ya, I'd love to replace this code with HttpClient code, where we
> could (1) set the UserAgent to be 'commons-vfs' (2) user HEAD and/or GET
> (3) have "follow redirects work" (I found a bug in JDK java.net.URL where
> it does not seem to follow relative redirects) and (4) only do (at most) on
> HEAD and one GET (if needed) per URL. [4 could be done with either
> underlying code.]
These are all good ideas. My plan for doing this was to extend the WebDAV
provider to handle plain HTTP as well, since it already sits on top of
HttpClient, and already does these things (uses OPTIONS instead of HEAD). It
just needs to be extended to handle non-dav resources.
> You say this project is active, but I've not seen a VFS committer chime in.
Apologies for that. I've been a little busier than I'd like recently.
> Any ideas how we entice one of them to work with us to help commit your/our
> work?
Just keep hassling us :) I will get your changes applied this weekend.
--
Adam
RE: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Jack <aj...@TrySybase.com>.
I like how you check in != null, and you catch/ignore close exceptions.
Seems solid.
I tell ya, I'd love to replace this code with HttpClient code, where we
could (1) set the UserAgent to be 'commons-vfs' (2) user HEAD and/or GET (3)
have "follow redirects work" (I found a bug in JDK java.net.URL where it
does not seem to follow relative redirects) and (4) only do (at most) on
HEAD and one GET (if needed) per URL. [4 could be done with either
underlying code.]
You say this project is active, but I've not seen a VFS committer chime in.
Any ideas how we entice one of them to work with us to help commit your/our
work?
regards,
Adam
-----Original Message-----
From: Anthony Eden [mailto:me@anthonyeden.com]
Sent: Thursday, May 15, 2003 8:50 AM
To: Jakarta Commons Users List
Subject: Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Adam,
Based on my understanding of the URLConnection class we will need to get
the InputStream after opening the connection and then make sure that
that stream is closed in the finally block. I have attached a diff of
changes against the current code.
Sincerely,
Anthony Eden
Adam Jack wrote:
>I think you are right, HEAD is a better approach. It may not be supported
by
>all servers, but it is (IMHO) worth trying with, like you said, a fall back
>approach to GET). An bunch of unsuccessful HEADs are probably less
>inefficient that a bunch of successful GETs were the data is thrown away.
>
>BTW: I'm getting report that my patch (and maybe your one later for
>getLastModified) are leading to stray sockets (at least w/ a HotSpot VM).
>I'm going to investigate to see if better clean-up is needed.
>
>That said, I wonder if we could totally rework UrlFileObject to have access
>the URLConnection once only (or once HEAD, once GET) and store
>information/contents locally, to attempt efficiency and not leaving
>connections open.
>
>regards
>
>Adam
>-----Original Message-----
>From: Anthony Eden [mailto:me@anthonyeden.com]
>Sent: Thursday, May 08, 2003 1:40 PM
>To: Jakarta Commons Users List
>Subject: Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
>
>
>It might be interesting to use the HEAD method instead of the default of
GET
>so that the entire content is not loaded. The only thing I don't know is
>whether or not all servers support the HEAD method. You may have to check
>for unsupported method errors and then try a GET if the HEAD fails. Of
>course all of this might be overkill, I am not sure.
>
>Sincerely,
>Anthony Eden
>
>Adam Jack wrote:
>
>
>>Ok, from the latest CVS code I see this in UrlFileObject:
>>
>> protected FileType doGetType() throws Exception
>> {
>> // Attempt to connect
>> try
>> {
>> url.openConnection().connect();
>> }
>> catch ( final FileNotFoundException e )
>> {
>> return FileType.IMAGINARY;
>> }
>> return FileType.FILE;
>> }
>>
>>This is effectively (I believe) just testing that the server exists. I see
>>it is attempting to catch the FileNotFoundException, but I don't think
>>
>>
>that
>
>
>>is kicking in without attempting to access the content. Adding these lines
>>to extract the response code (and looking for a 200) seems to help for
>>
>>
>HTTP.
>
>
>>I am sure there are imperfections to do with some other return types being
>>valid (and personally I'd love to see use of URL replaced with HttpClient
>>and with a user-agent set, etc.) but I believe it is a step closer to
>>correct. Directory redirects and such might mess with it, but I *think*
>>
>>
>the
>
>
>>default follow redirects copes w/ those.
>>
>>[BTW: I don't know if this code is ever used on local files, but I believe
>>that code path ought not be affected by my changes.]
>>
>> /**
>> * Determines the type of the file.
>> */
>> protected FileType doGetType()
>> {
>> FileType fileType = FileType.FILE;
>> // Attempt to connect & check status
>> try
>> {
>> URLConnection conn = url.openConnection();
>> conn.connect();
>> if (conn instanceof HttpURLConnection)
>> {
>> int status = ((HttpURLConnection)conn).getResponseCode();
>> // 200 is good, maybe add more later...
>> if ( HttpURLConnection.HTTP_OK != status)
>> fileType = FileType.IMAGINARY;
>> }
>> }
>> catch (final Exception e)
>> {
>> fileType = FileType.IMAGINARY;
>> }
>> return fileType;
>> }
>>
>>I am sorry this isn't a CVS patch, I've not learned how to do that yet,
>>
>>
>but
>
>
>>would a Commons VFS committer please look at this for me?
>>
>>regards
>>
>>Adam
>>-----Original Message-----
>>From: Adam Jack [mailto:ajack@trysybase.com]
>>Sent: Thursday, May 01, 2003 6:29 AM
>>To: 'Jakarta Commons Users List'
>>Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
>>expected...
>>
>>
>>
>> > Basically I get "true" even when the object fails to exist. Anybody
>>
>>
>else
>
>
>> > seen this? Is it me, or ought I attempt to log a bug report?
>>
>> I'm seeing the same problem. It's a bug.
>>
>>Hmm, I went to try to log an issue, created an account, was told I didn't
>>have permission for the module, and then could not find a role to request
>>that seems appropriate for commons VFS.
>>
>> http://scarab.werken.com/scarab/issues/
>>
>>Any hints on how I log this?
>>
>>regards
>>
>>Adam
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Anthony Eden <me...@anthonyeden.com>.
Adam,
Based on my understanding of the URLConnection class we will need to get
the InputStream after opening the connection and then make sure that
that stream is closed in the finally block. I have attached a diff of
changes against the current code.
Sincerely,
Anthony Eden
Adam Jack wrote:
>I think you are right, HEAD is a better approach. It may not be supported by
>all servers, but it is (IMHO) worth trying with, like you said, a fall back
>approach to GET). An bunch of unsuccessful HEADs are probably less
>inefficient that a bunch of successful GETs were the data is thrown away.
>
>BTW: I'm getting report that my patch (and maybe your one later for
>getLastModified) are leading to stray sockets (at least w/ a HotSpot VM).
>I'm going to investigate to see if better clean-up is needed.
>
>That said, I wonder if we could totally rework UrlFileObject to have access
>the URLConnection once only (or once HEAD, once GET) and store
>information/contents locally, to attempt efficiency and not leaving
>connections open.
>
>regards
>
>Adam
>-----Original Message-----
>From: Anthony Eden [mailto:me@anthonyeden.com]
>Sent: Thursday, May 08, 2003 1:40 PM
>To: Jakarta Commons Users List
>Subject: Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
>
>
>It might be interesting to use the HEAD method instead of the default of GET
>so that the entire content is not loaded. The only thing I don't know is
>whether or not all servers support the HEAD method. You may have to check
>for unsupported method errors and then try a GET if the HEAD fails. Of
>course all of this might be overkill, I am not sure.
>
>Sincerely,
>Anthony Eden
>
>Adam Jack wrote:
>
>
>>Ok, from the latest CVS code I see this in UrlFileObject:
>>
>> protected FileType doGetType() throws Exception
>> {
>> // Attempt to connect
>> try
>> {
>> url.openConnection().connect();
>> }
>> catch ( final FileNotFoundException e )
>> {
>> return FileType.IMAGINARY;
>> }
>> return FileType.FILE;
>> }
>>
>>This is effectively (I believe) just testing that the server exists. I see
>>it is attempting to catch the FileNotFoundException, but I don't think
>>
>>
>that
>
>
>>is kicking in without attempting to access the content. Adding these lines
>>to extract the response code (and looking for a 200) seems to help for
>>
>>
>HTTP.
>
>
>>I am sure there are imperfections to do with some other return types being
>>valid (and personally I'd love to see use of URL replaced with HttpClient
>>and with a user-agent set, etc.) but I believe it is a step closer to
>>correct. Directory redirects and such might mess with it, but I *think*
>>
>>
>the
>
>
>>default follow redirects copes w/ those.
>>
>>[BTW: I don't know if this code is ever used on local files, but I believe
>>that code path ought not be affected by my changes.]
>>
>> /**
>> * Determines the type of the file.
>> */
>> protected FileType doGetType()
>> {
>> FileType fileType = FileType.FILE;
>> // Attempt to connect & check status
>> try
>> {
>> URLConnection conn = url.openConnection();
>> conn.connect();
>> if (conn instanceof HttpURLConnection)
>> {
>> int status = ((HttpURLConnection)conn).getResponseCode();
>> // 200 is good, maybe add more later...
>> if ( HttpURLConnection.HTTP_OK != status)
>> fileType = FileType.IMAGINARY;
>> }
>> }
>> catch (final Exception e)
>> {
>> fileType = FileType.IMAGINARY;
>> }
>> return fileType;
>> }
>>
>>I am sorry this isn't a CVS patch, I've not learned how to do that yet,
>>
>>
>but
>
>
>>would a Commons VFS committer please look at this for me?
>>
>>regards
>>
>>Adam
>>-----Original Message-----
>>From: Adam Jack [mailto:ajack@trysybase.com]
>>Sent: Thursday, May 01, 2003 6:29 AM
>>To: 'Jakarta Commons Users List'
>>Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
>>expected...
>>
>>
>>
>> > Basically I get "true" even when the object fails to exist. Anybody
>>
>>
>else
>
>
>> > seen this? Is it me, or ought I attempt to log a bug report?
>>
>> I'm seeing the same problem. It's a bug.
>>
>>Hmm, I went to try to log an issue, created an account, was told I didn't
>>have permission for the module, and then could not find a role to request
>>that seems appropriate for commons VFS.
>>
>> http://scarab.werken.com/scarab/issues/
>>
>>Any hints on how I log this?
>>
>>regards
>>
>>Adam
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 25 Jun 2003 02:52 am, Anthony Eden wrote:
> Here is the full patch for UrlFileObject again.
I missed this one the other day. Sorry about that. It's been applied now.
--
Adam
Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Anthony Eden <me...@anthonyeden.com>.
Here is the full patch for UrlFileObject again.
Sincerely,
Anthony Eden
RE: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Jack <aj...@TrySybase.com>.
I think you are right, HEAD is a better approach. It may not be supported by
all servers, but it is (IMHO) worth trying with, like you said, a fall back
approach to GET). An bunch of unsuccessful HEADs are probably less
inefficient that a bunch of successful GETs were the data is thrown away.
BTW: I'm getting report that my patch (and maybe your one later for
getLastModified) are leading to stray sockets (at least w/ a HotSpot VM).
I'm going to investigate to see if better clean-up is needed.
That said, I wonder if we could totally rework UrlFileObject to have access
the URLConnection once only (or once HEAD, once GET) and store
information/contents locally, to attempt efficiency and not leaving
connections open.
regards
Adam
-----Original Message-----
From: Anthony Eden [mailto:me@anthonyeden.com]
Sent: Thursday, May 08, 2003 1:40 PM
To: Jakarta Commons Users List
Subject: Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
It might be interesting to use the HEAD method instead of the default of GET
so that the entire content is not loaded. The only thing I don't know is
whether or not all servers support the HEAD method. You may have to check
for unsupported method errors and then try a GET if the HEAD fails. Of
course all of this might be overkill, I am not sure.
Sincerely,
Anthony Eden
Adam Jack wrote:
> Ok, from the latest CVS code I see this in UrlFileObject:
>
> protected FileType doGetType() throws Exception
> {
> // Attempt to connect
> try
> {
> url.openConnection().connect();
> }
> catch ( final FileNotFoundException e )
> {
> return FileType.IMAGINARY;
> }
> return FileType.FILE;
> }
>
> This is effectively (I believe) just testing that the server exists. I see
> it is attempting to catch the FileNotFoundException, but I don't think
that
> is kicking in without attempting to access the content. Adding these lines
> to extract the response code (and looking for a 200) seems to help for
HTTP.
> I am sure there are imperfections to do with some other return types being
> valid (and personally I'd love to see use of URL replaced with HttpClient
> and with a user-agent set, etc.) but I believe it is a step closer to
> correct. Directory redirects and such might mess with it, but I *think*
the
> default follow redirects copes w/ those.
>
> [BTW: I don't know if this code is ever used on local files, but I believe
> that code path ought not be affected by my changes.]
>
> /**
> * Determines the type of the file.
> */
> protected FileType doGetType()
> {
> FileType fileType = FileType.FILE;
> // Attempt to connect & check status
> try
> {
> URLConnection conn = url.openConnection();
> conn.connect();
> if (conn instanceof HttpURLConnection)
> {
> int status = ((HttpURLConnection)conn).getResponseCode();
> // 200 is good, maybe add more later...
> if ( HttpURLConnection.HTTP_OK != status)
> fileType = FileType.IMAGINARY;
> }
> }
> catch (final Exception e)
> {
> fileType = FileType.IMAGINARY;
> }
> return fileType;
> }
>
> I am sorry this isn't a CVS patch, I've not learned how to do that yet,
but
> would a Commons VFS committer please look at this for me?
>
> regards
>
> Adam
> -----Original Message-----
> From: Adam Jack [mailto:ajack@trysybase.com]
> Sent: Thursday, May 01, 2003 6:29 AM
> To: 'Jakarta Commons Users List'
> Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
> expected...
>
>
>
> > Basically I get "true" even when the object fails to exist. Anybody
else
> > seen this? Is it me, or ought I attempt to log a bug report?
>
> I'm seeing the same problem. It's a bug.
>
> Hmm, I went to try to log an issue, created an account, was told I didn't
> have permission for the module, and then could not find a role to request
> that seems appropriate for commons VFS.
>
> http://scarab.werken.com/scarab/issues/
>
> Any hints on how I log this?
>
> regards
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Anthony Eden <me...@anthonyeden.com>.
It might be interesting to use the HEAD method instead of the default of GET so that the entire content is not loaded. The only thing I don't know is whether or not all servers support the HEAD method. You may have to check for unsupported method errors and then try a GET if the HEAD fails. Of course all of this might be overkill, I am not sure.
Sincerely,
Anthony Eden
Adam Jack wrote:
> Ok, from the latest CVS code I see this in UrlFileObject:
>
> protected FileType doGetType() throws Exception
> {
> // Attempt to connect
> try
> {
> url.openConnection().connect();
> }
> catch ( final FileNotFoundException e )
> {
> return FileType.IMAGINARY;
> }
> return FileType.FILE;
> }
>
> This is effectively (I believe) just testing that the server exists. I see
> it is attempting to catch the FileNotFoundException, but I don't think that
> is kicking in without attempting to access the content. Adding these lines
> to extract the response code (and looking for a 200) seems to help for HTTP.
> I am sure there are imperfections to do with some other return types being
> valid (and personally I'd love to see use of URL replaced with HttpClient
> and with a user-agent set, etc.) but I believe it is a step closer to
> correct. Directory redirects and such might mess with it, but I *think* the
> default follow redirects copes w/ those.
>
> [BTW: I don't know if this code is ever used on local files, but I believe
> that code path ought not be affected by my changes.]
>
> /**
> * Determines the type of the file.
> */
> protected FileType doGetType()
> {
> FileType fileType = FileType.FILE;
> // Attempt to connect & check status
> try
> {
> URLConnection conn = url.openConnection();
> conn.connect();
> if (conn instanceof HttpURLConnection)
> {
> int status = ((HttpURLConnection)conn).getResponseCode();
> // 200 is good, maybe add more later...
> if ( HttpURLConnection.HTTP_OK != status)
> fileType = FileType.IMAGINARY;
> }
> }
> catch (final Exception e)
> {
> fileType = FileType.IMAGINARY;
> }
> return fileType;
> }
>
> I am sorry this isn't a CVS patch, I've not learned how to do that yet, but
> would a Commons VFS committer please look at this for me?
>
> regards
>
> Adam
> -----Original Message-----
> From: Adam Jack [mailto:ajack@trysybase.com]
> Sent: Thursday, May 01, 2003 6:29 AM
> To: 'Jakarta Commons Users List'
> Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
> expected...
>
>
>
> > Basically I get "true" even when the object fails to exist. Anybody else
> > seen this? Is it me, or ought I attempt to log a bug report?
>
> I'm seeing the same problem. It's a bug.
>
> Hmm, I went to try to log an issue, created an account, was told I didn't
> have permission for the module, and then could not find a role to request
> that seems appropriate for commons VFS.
>
> http://scarab.werken.com/scarab/issues/
>
> Any hints on how I log this?
>
> regards
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
[VFS] [PATCH] UrlFileObject.exists (when HTTP)
Posted by Adam Jack <aj...@TrySybase.com>.
Ok, from the latest CVS code I see this in UrlFileObject:
protected FileType doGetType() throws Exception
{
// Attempt to connect
try
{
url.openConnection().connect();
}
catch ( final FileNotFoundException e )
{
return FileType.IMAGINARY;
}
return FileType.FILE;
}
This is effectively (I believe) just testing that the server exists. I see
it is attempting to catch the FileNotFoundException, but I don't think that
is kicking in without attempting to access the content. Adding these lines
to extract the response code (and looking for a 200) seems to help for HTTP.
I am sure there are imperfections to do with some other return types being
valid (and personally I'd love to see use of URL replaced with HttpClient
and with a user-agent set, etc.) but I believe it is a step closer to
correct. Directory redirects and such might mess with it, but I *think* the
default follow redirects copes w/ those.
[BTW: I don't know if this code is ever used on local files, but I believe
that code path ought not be affected by my changes.]
/**
* Determines the type of the file.
*/
protected FileType doGetType()
{
FileType fileType = FileType.FILE;
// Attempt to connect & check status
try
{
URLConnection conn = url.openConnection();
conn.connect();
if (conn instanceof HttpURLConnection)
{
int status = ((HttpURLConnection)conn).getResponseCode();
// 200 is good, maybe add more later...
if ( HttpURLConnection.HTTP_OK != status)
fileType = FileType.IMAGINARY;
}
}
catch (final Exception e)
{
fileType = FileType.IMAGINARY;
}
return fileType;
}
I am sorry this isn't a CVS patch, I've not learned how to do that yet, but
would a Commons VFS committer please look at this for me?
regards
Adam
-----Original Message-----
From: Adam Jack [mailto:ajack@trysybase.com]
Sent: Thursday, May 01, 2003 6:29 AM
To: 'Jakarta Commons Users List'
Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
expected...
> Basically I get "true" even when the object fails to exist. Anybody else
> seen this? Is it me, or ought I attempt to log a bug report?
I'm seeing the same problem. It's a bug.
Hmm, I went to try to log an issue, created an account, was told I didn't
have permission for the module, and then could not find a role to request
that seems appropriate for commons VFS.
http://scarab.werken.com/scarab/issues/
Any hints on how I log this?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [VFS] FileObject.exists (when HTTP) seems not to work as expected...
Posted by Adam Jack <aj...@TrySybase.com>.
> Basically I get "true" even when the object fails to exist. Anybody else
> seen this? Is it me, or ought I attempt to log a bug report?
I'm seeing the same problem. It's a bug.
Hmm, I went to try to log an issue, created an account, was told I didn't
have permission for the module, and then could not find a role to request
that seems appropriate for commons VFS.
http://scarab.werken.com/scarab/issues/
Any hints on how I log this?
regards
Adam
Re: [VFS] FileObject.exists (when HTTP) seems not to work as expected...
Posted by Adam Murdoch <ad...@apache.org>.
On Thu, 1 May 2003 01:55 pm, Adam Jack wrote:
> I am using commons VFS 1.0 and believe I am experiencing a problem with
> FileObject.exists. The HttpClient I am running over is 2.0 alpha 2. I
> wonder if somehow a change in the latter has caused the former to fail.
The http stuff uses java.net.URL rather than HttpClient (at this stage), so
that won't be causing the problem.
> Basically I get "true" even when the object fails to exist. Anybody else
> seen this? Is it me, or ought I attempt to log a bug report?
I'm seeing the same problem. It's a bug.
--
Adam