[jira] [Commented] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586963#comment-13586963
]
Jean-Marc Borer commented on VFS-428:
-
I am having the same kind of issues. After a long investigation whith try and
errors, I found out:
*)
org.apache.commons.httpclient.methods.EntityEnclosingMethod.setFollowRedirects(false)
is actually prevented by HTTPClient 3.x, because of RFC 2616. There is nothing
you can do here. The solution would probably be to upgrade to HTTPClient 4,
which seems to much better support redirection. However, even if VFS moves to
the new version of HTTPClient, the Jackrabbit guys have not plans to upgrade:
too much work and stick to to 3.x for a unknown time.
*) trailing slash support is tricky apparently. I need it also for supporting
list feature with HTTP scheme. However internally VFS wants paths without
trailing slashes. This is fine if your webserver is configured to redirect
paths without trailing slash to trailing ones. However this is problematic when
you try to access the same path with WebDAV (my case) where the redirection
will not be supported.
Very tricky issue.
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586963#comment-13586963
]
Jean-Marc Borer edited comment on VFS-428 at 2/26/13 9:38 AM:
--
I am having the same kind of issues. After a long investigation whith try and
errors, I found out:
1)
org.apache.commons.httpclient.methods.EntityEnclosingMethod.setFollowRedirects(false)
is actually prevented by HTTPClient 3.x, because of RFC 2616. There is nothing
you can do here. The solution would probably be to upgrade to HTTPClient 4,
which seems to much better support redirection. However, even if VFS moves to
the new version of HTTPClient, the Jackrabbit guys have not plans to upgrade:
too much work and stick to to 3.x for a unknown time.
2) trailing slash support is tricky apparently. I need it also for supporting
list feature with HTTP scheme. However internally VFS wants paths without
trailing slashes. This is fine if your webserver is configured to redirect
paths without trailing slash to trailing ones. However this is problematic when
you try to access the same path with WebDAV (my case) where the redirection
will not be supported.
Very tricky issue.
was (Author: jmborer):
I am having the same kind of issues. After a long investigation whith try
and errors, I found out:
*)
org.apache.commons.httpclient.methods.EntityEnclosingMethod.setFollowRedirects(false)
is actually prevented by HTTPClient 3.x, because of RFC 2616. There is nothing
you can do here. The solution would probably be to upgrade to HTTPClient 4,
which seems to much better support redirection. However, even if VFS moves to
the new version of HTTPClient, the Jackrabbit guys have not plans to upgrade:
too much work and stick to to 3.x for a unknown time.
*) trailing slash support is tricky apparently. I need it also for supporting
list feature with HTTP scheme. However internally VFS wants paths without
trailing slashes. This is fine if your webserver is configured to redirect
paths without trailing slash to trailing ones. However this is problematic when
you try to access the same path with WebDAV (my case) where the redirection
will not be supported.
Very tricky issue.
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-465) Cannot delete an empty directory
Jean-Marc Borer created VFS-465: --- Summary: Cannot delete an empty directory Key: VFS-465 URL: https://issues.apache.org/jira/browse/VFS-465 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Jean-Marc Borer WebDAV seems to always include the parent folder when returning a list of children for a directory. In VFS, it is checked that a folder is empty before allowing to delete it. However with WebDAV, all empty dirs return one entry (themselfs) which prevents the deletion of the directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-465) WebDAV: Cannot delete an empty directory
[ https://issues.apache.org/jira/browse/VFS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Borer updated VFS-465: Summary: WebDAV: Cannot delete an empty directory (was: Cannot delete an empty directory) WebDAV: Cannot delete an empty directory Key: VFS-465 URL: https://issues.apache.org/jira/browse/VFS-465 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Jean-Marc Borer WebDAV seems to always include the parent folder when returning a list of children for a directory. In VFS, it is checked that a folder is empty before allowing to delete it. However with WebDAV, all empty dirs return one entry (themselfs) which prevents the deletion of the directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-466) UserAuthenticationData is too limited
Joerg Schaible created VFS-466: -- Summary: UserAuthenticationData is too limited Key: VFS-466 URL: https://issues.apache.org/jira/browse/VFS-466 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Fix For: 2.1 The UserAuthenticationData should be used as vehicle to transport authentication data to the individual providers. While it is open for new authentication data types, it limits the values of the data to be a character array. Therefore it does not fit for authentication with private keys or certificates like it is possible with e.g. SFTP or FTPS. For a proper support of the latter authentication types, we have to support arbitrary value types in the UserAuthenticationData. To add this functionality without breaking binary compatibility, we have to make a compromise by adding new getter/setter methods to the class that will replace the old (now deprecated ones), because the getter will now return other types than char[]. This patch is used as base for VFS-283 and for support of client certificates with FTPS (no JIRA issue yet). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-467) WebDAV: list children returns source directory instead of ignoring it
Jean-Marc Borer created VFS-467: --- Summary: WebDAV: list children returns source directory instead of ignoring it Key: VFS-467 URL: https://issues.apache.org/jira/browse/VFS-467 Project: Commons VFS Issue Type: Bug Reporter: Jean-Marc Borer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
Matthias Richter created CONFIGURATION-527: -- Summary: clearPropertyDirect() in AbstractConfiguration should be abstract Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-467) WebDAV: list children returns source directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated VFS-467:
Description:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
Affects Version/s: 2.1
2.0
WebDAV: list children returns source directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-467) WebDAV: list children returns parent directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated VFS-467:
Summary: WebDAV: list children returns parent directory instead of ignoring
it (was: WebDAV: list children returns source directory instead of ignoring it)
WebDAV: list children returns parent directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Richter updated CONFIGURATION-527: --- Attachment: patch Possible solution clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Richter updated CONFIGURATION-527: --- Attachment: (was: patch) clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587071#comment-13587071 ] Matthias Richter edited comment on CONFIGURATION-527 at 2/26/13 12:39 PM: -- Possible solution, see patch file. was (Author: richtmat): Possible solution clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Richter updated CONFIGURATION-527: --- Attachment: patch.diff clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587090#comment-13587090
]
Gary Gregory commented on VFS-428:
--
Tangent: We should migrate to HTTPClient 4 anyway.
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587092#comment-13587092 ] Joerg Schaible commented on CONFIGURATION-527: -- IMHO, this will break binary compatibility. Any custom class that did not yet overwrite this method will now suddenly fail with an Error, if the new version is used as drop-in. clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587095#comment-13587095
]
Jean-Marc Borer commented on VFS-428:
-
Yes, but we have then either to convince the JackRabbit team to upgrade or use
another webdav library like https://code.google.com/p/sardine/ which already
uses HTTPClient 4
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587095#comment-13587095
]
Jean-Marc Borer edited comment on VFS-428 at 2/26/13 1:05 PM:
--
Yes, but we have then either to convince the JackRabbit team to upgrade or to
use another webdav library like https://code.google.com/p/sardine/ which
already uses HTTPClient 4
was (Author: jmborer):
Yes, but we have then either to convince the JackRabbit team to upgrade or
use another webdav library like https://code.google.com/p/sardine/ which
already uses HTTPClient 4
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587098#comment-13587098 ] Matthias Richter commented on CONFIGURATION-527: Yes indeed. Still questionable to have the difference in addPropertyDirect() and clearPropertyDirect(). Now one needs to decide between binary compatibility and abstraction cohesion, I guess. I would tend to vote for the latter, but it's up to you guys... clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-467) WebDAV: list children returns parent directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587105#comment-13587105
]
Jean-Marc Borer commented on VFS-467:
-
Not sure about my fix, but I suppose WebDAV returns always relatives paths. So
test should be:
if (name.getPath().equals(response.getHref()))
{
continue;
}
WebDAV: list children returns parent directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-465) WebDAV: Cannot delete an empty directory
[ https://issues.apache.org/jira/browse/VFS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587108#comment-13587108 ] Jean-Marc Borer commented on VFS-465: - The issue is in WebdavFileObject where the source directory should be ignored but the test is not formed properly. Therefore it is included and consequently, delete will not work. WebDAV: Cannot delete an empty directory Key: VFS-465 URL: https://issues.apache.org/jira/browse/VFS-465 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Jean-Marc Borer WebDAV seems to always include the parent folder when returning a list of children for a directory. In VFS, it is checked that a folder is empty before allowing to delete it. However with WebDAV, all empty dirs return one entry (themselfs) which prevents the deletion of the directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-465) WebDAV: Cannot delete an empty directory
[ https://issues.apache.org/jira/browse/VFS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587109#comment-13587109 ] Jean-Marc Borer commented on VFS-465: - If issue https://issues.apache.org/jira/browse/VFS-467 is fixed, then it will work properly. WebDAV: Cannot delete an empty directory Key: VFS-465 URL: https://issues.apache.org/jira/browse/VFS-465 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Jean-Marc Borer WebDAV seems to always include the parent folder when returning a list of children for a directory. In VFS, it is checked that a folder is empty before allowing to delete it. However with WebDAV, all empty dirs return one entry (themselfs) which prevents the deletion of the directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587111#comment-13587111 ] Joerg Schaible commented on CONFIGURATION-527: -- It simply means that this change has to be postponed to version 2.0. clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587113#comment-13587113 ] Matthias Richter commented on CONFIGURATION-527: That's fine for me. I just stumbled over it when implementing the AbstractConfiguration. The patch file attached is fine, though? clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587117#comment-13587117
]
Gary Gregory commented on VFS-428:
--
VFS can migrate to HC 4 for HTTP[S]. What ever happens in the WebDAV provider
is it's business. HC3 and 4 can coexist since they are packaged separately.
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-428) DavException: (301) Moved Permanently
[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587119#comment-13587119
]
Gary Gregory commented on VFS-428:
--
2) trailing slash support is tricky apparently. I need it also for supporting
list feature with HTTP scheme. However internally VFS wants paths without
trailing slashes. This is fine if your webserver is configured to redirect
paths without trailing slash to trailing ones. However this is problematic when
you try to access the same path with WebDAV (my case) where the redirection
will not be supported.
I've run into this pain as well :( I'm not sure how to proceed on this one
yet...
DavException: (301) Moved Permanently
--
Key: VFS-428
URL: https://issues.apache.org/jira/browse/VFS-428
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Environment: Apache 2.2.22 as Testerver and setted up like
http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
password)
Reporter: Robert Kornmesser
Priority: Blocker
Labels: webdav
Running the WebdavProviderTestCase using mvn -P webdav clean test
-Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
-Dtest=WebdavProviderTestCase results in
{code}DavException: (301) Moved Permanently
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec
FAILURE!
Results :
Tests in error:
junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
Could not determine the type of file
webdav://vfsusr:@localhost/vfstest/read-tests.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{code}
The deeper Problem is, that the HttpClient using by VFS does not append a
trailing slash and mod_dir of httpd has DirectorySlash On per default. So
httpd send 301 redirect to the same url with / appended.
I know that for this reason of problematic webdav client apache introduced
redirect-carefully for some user agents using the BrowserMatch directive.
So I just tried adding the following into my Directory directive
{code}
BrowserMatch ^Jakarta-Commons-VFS redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.0 redirect-carefully
BrowserMatch ^Jakarta Commons-HttpClient/3.1 redirect-carefully
{code}
Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
because of two requests from commons vfs using two different user agents.
But instead of solving the issue, I get for every FileObject.getChildren()
call at least one FileObject of type imaginary with the same basename as the
parent. Thats not a problem at all (besides that this is totally wrong!) but
deleting a parent just dont work anymore, because of an *non-existent*
imaginary file inside the dir which cannot be deleted of course.
To cut a long story short, what is the right httpd webdav server config to
use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587122#comment-13587122 ] Joerg Schaible commented on CONFIGURATION-527: -- It's perfect :) clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (VFS-467) WebDAV: list children returns parent directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587105#comment-13587105
]
Jean-Marc Borer edited comment on VFS-467 at 2/26/13 1:55 PM:
--
Not sure about my fix, but I suppose WebDAV returns always relatives paths. So
test should be:
private boolean isCurrentFile(String href, URLFileName fileName)
{
String name = fileName.getPath();
if (href.endsWith(/) !name.endsWith(/))
{
name += /;
}
return href.equals(name);
}
was (Author: jmborer):
Not sure about my fix, but I suppose WebDAV returns always relatives paths.
So test should be:
if (name.getPath().equals(response.getHref()))
{
continue;
}
WebDAV: list children returns parent directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-467) WebDAV: list children returns parent directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated VFS-467:
Description:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
String name = hrefString(fileName);
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
was:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
WebDAV: list children returns parent directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
String name = hrefString(fileName);
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-467) WebDAV: list children returns parent directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated VFS-467:
Description:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
private boolean isCurrentFile(String href, URLFileName fileName)
{
String name = hrefString(fileName);
if (href.endsWith(/) !name.endsWith(/))
{
name += /;
}
return href.equals(name);
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
was:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
private boolean isCurrentFile(String href, URLFileName fileName)
{
String name = hrefString(fileName);
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
WebDAV: list children returns parent directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
private boolean isCurrentFile(String href, URLFileName fileName)
{
String name = hrefString(fileName);
if (href.endsWith(/) !name.endsWith(/))
{
name += /;
}
return href.equals(name);
}
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-467) WebDAV: list children returns parent directory instead of ignoring it
[
https://issues.apache.org/jira/browse/VFS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated VFS-467:
Description:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
private boolean isCurrentFile(String href, URLFileName fileName)
{
String name = hrefString(fileName);
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
was:
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
String name = hrefString(fileName);
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
WebDAV: list children returns parent directory instead of ignoring it
-
Key: VFS-467
URL: https://issues.apache.org/jira/browse/VFS-467
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0, 2.1
Reporter: Jean-Marc Borer
WebDAV seems to always include the parent folder when returning a list
of children for a directory. This is due to a wrong test in WebdavFileObject
doListChildrenResolved:
if (isCurrentFile(response.getHref(), name))
{
continue;
}
where
private boolean isCurrentFile(String href, URLFileName fileName)
{
String name = hrefString(fileName);
where the parent dir returned in the WedbDAV response should be ignored.
However the test compares a RELATIVE href (first arg), with an ASBOLUTE href
(second arg)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FILEUPLOAD-214) ServletFileUpload only accepts POST requests
Matthew Runo created FILEUPLOAD-214: --- Summary: ServletFileUpload only accepts POST requests Key: FILEUPLOAD-214 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-214 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2.2 Environment: Spring 3.x Reporter: Matthew Runo Priority: Minor ServletFileUpload is hard coded to only accept POST requests. See implementation of isMultipartContent. Since PUT (and other) requests might also be used to upload files in REST apis, this restriction should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EMAIL-124) Header values are folded twice and thus creating defective emails
[ https://issues.apache.org/jira/browse/EMAIL-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587310#comment-13587310 ] Stefan Schueffler commented on EMAIL-124: - Hi, due to my vacational out of office, i unfortunately can not test your commit. But as far as i can tell from reading your commit mentioned above, your fix looks exactly the same what i did while analyzing this issue. Regards, Stefan Header values are folded twice and thus creating defective emails - Key: EMAIL-124 URL: https://issues.apache.org/jira/browse/EMAIL-124 Project: Commons Email Issue Type: Bug Affects Versions: 1.3 Reporter: Stefan Schueffler Priority: Blocker Fix For: 1.3.1 Original Estimate: 5m Remaining Estimate: 5m With EMAIL-98, header values now are folded by commons-email. Unfortunately, they are folded twice: once in Mail.addHeader or Mail.setHeaders, and once again in Mail.buildMimeMessage() while iterating over the headers. This results (in our test cases) in corrupted mail header lines having additional blank lines between the first and second line of a folded value - and thus ends in corrupted mails (as all headers after the first blank line are threatened as mail-body-content). As this renders additional headers useless in commons-mail and corrupts every mail having additionl headers with longer-than-folding-size values, i set the priority to blocker. The fix seems to be easy: just fold either in addHeader and setHeaders, or in buildMimeMessage (but not in both). My preferred solution would be to fold in buildMimeMessage, and to store the values as-is in addHeader and setHeaders so one is able to work with the plain values (if neccessary) until the mail is actually build and send. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
michael tibbetts created CLI-232: Summary: Download link gives HTTP/1.1 403 Forbidden Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-242) Add Equator interface for more powerful collections
[
https://issues.apache.org/jira/browse/COLLECTIONS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587337#comment-13587337
]
Matt Lachman commented on COLLECTIONS-242:
--
I found this after posting for something similar on StackOverflow
[here|http://stackoverflow.com/questions/15094818/compare-two-java-collections-using-comparator-instead-of-equals].
The Equator interface seems to have more potential uses (such as Maps and Sets
using it for determining uniqueness).
I think it would also be worthwhile to overload {{isEqualCollection}} on
{{CollectionUtils}} using this interface:
{code:java}
public static boolean isEqualCollection(Collection a,
Collection b, Equator e)
{code}
If it makes sense, I can file this as a separate enhancement request dependent
on this issue.
Add Equator interface for more powerful collections
---
Key: COLLECTIONS-242
URL: https://issues.apache.org/jira/browse/COLLECTIONS-242
Project: Commons Collections
Issue Type: Improvement
Components: Comparator
Reporter: Stephen Kestle
Assignee: Stephen Kestle
Fix For: 4.0
Java has Comparable and Comparator to compare objects, and objects have an
equals() method. But there is no interface for when an object has multiple
ways of being equal.
e.g.: an database object that has a name, code and a value. Equality could be
based on:
* database id
* code
* name and code
* case-insensitive name
When extended to collections, this allows us to search for specific
values (with an EqualsPredicate that takes an Equator), and implement
Maps and Sets that use specific equators to determine uniqueness.
I propose that it has two methods:
boolean equate();
int hash();
I shall upload some files when I next get some time.
NB: This ticket is a summary of the email conversation begun on 5 Jan 2007:
equator interface
(http://archives.devshed.com/forums/java-118/equator-interface-2126195.html).
Stephen C made reference there to creating a FlexiMap, but in my mind,
that's additional to this issue (this interface still needs to be created to
be able to stand alone).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587341#comment-13587341 ] Olivier Lamy (*$^¨%`£) commented on CLI-232: I will take care even if I cannot assign to myself :-) Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587376#comment-13587376 ] Olivier Lamy (*$^¨%`£) commented on CLI-232: fixed. can someone with karma close it ? Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587376#comment-13587376 ] Olivier Lamy (*$^¨%`£) edited comment on CLI-232 at 2/26/13 6:39 PM: - fixed. can someone with karma close it ? and/or add me in the correct group :-) was (Author: olamy): fixed. can someone with karma close it ? Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587381#comment-13587381 ] michael tibbetts commented on CLI-232: -- Following the newly enabled download link, I get a 404 from at least 4 separate download mirrors. Do you want a new bug on this? http://mirror.sdunix.com/apache/ http://apache.claz.org/ http://apache.mirrors.hoobly.com/ http://apache.mirrors.tds.net//commons/cli/binaries/commons-cli-1.3-bin.tar.gz Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-396) New DynamicIterator class.
[ https://issues.apache.org/jira/browse/COLLECTIONS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Rodriguez updated COLLECTIONS-396: --- Attachment: LazyIteratorChain.java LazyIteratorChainTest.java Updated name and package. New DynamicIterator class. -- Key: COLLECTIONS-396 URL: https://issues.apache.org/jira/browse/COLLECTIONS-396 Project: Commons Collections Issue Type: New Feature Components: Iterator Environment: Java 1.5 or greater Reporter: Jeff Rodriguez Priority: Minor Labels: dynamic, iterator, new Attachments: LazyIteratorChain.java, LazyIteratorChainTest.java Original Estimate: 1h Remaining Estimate: 1h I would like to submit my DynamicIterator class for inclusion in Commons Collections. Description from JavaDoc: Iterates over the elements of an inner iterator provided by nextIterator() Once the inner iterator's hasNext() method returns false, nextIterator() will be called to obtain another iterator, and so on until nextIterator() returns null. The use case I had in mind for this class was the paged web service. A web service returns a list of results, which are paginated. Once a page's results are exhausted, nextIterator() can go fetch the next page for iteration. This class, and accompanying test class are my original works. I have released them into the public domain, feel free to use the appropriate ASF license. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-396) New DynamicIterator class.
[ https://issues.apache.org/jira/browse/COLLECTIONS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Rodriguez updated COLLECTIONS-396: --- Attachment: (was: DynamicIterator.java) New DynamicIterator class. -- Key: COLLECTIONS-396 URL: https://issues.apache.org/jira/browse/COLLECTIONS-396 Project: Commons Collections Issue Type: New Feature Components: Iterator Environment: Java 1.5 or greater Reporter: Jeff Rodriguez Priority: Minor Labels: dynamic, iterator, new Attachments: LazyIteratorChain.java, LazyIteratorChainTest.java Original Estimate: 1h Remaining Estimate: 1h I would like to submit my DynamicIterator class for inclusion in Commons Collections. Description from JavaDoc: Iterates over the elements of an inner iterator provided by nextIterator() Once the inner iterator's hasNext() method returns false, nextIterator() will be called to obtain another iterator, and so on until nextIterator() returns null. The use case I had in mind for this class was the paged web service. A web service returns a list of results, which are paginated. Once a page's results are exhausted, nextIterator() can go fetch the next page for iteration. This class, and accompanying test class are my original works. I have released them into the public domain, feel free to use the appropriate ASF license. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-396) New DynamicIterator class.
[ https://issues.apache.org/jira/browse/COLLECTIONS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Rodriguez updated COLLECTIONS-396: --- Attachment: (was: DynamicIteratorTest.java) New DynamicIterator class. -- Key: COLLECTIONS-396 URL: https://issues.apache.org/jira/browse/COLLECTIONS-396 Project: Commons Collections Issue Type: New Feature Components: Iterator Environment: Java 1.5 or greater Reporter: Jeff Rodriguez Priority: Minor Labels: dynamic, iterator, new Attachments: LazyIteratorChain.java, LazyIteratorChainTest.java Original Estimate: 1h Remaining Estimate: 1h I would like to submit my DynamicIterator class for inclusion in Commons Collections. Description from JavaDoc: Iterates over the elements of an inner iterator provided by nextIterator() Once the inner iterator's hasNext() method returns false, nextIterator() will be called to obtain another iterator, and so on until nextIterator() returns null. The use case I had in mind for this class was the paged web service. A web service returns a list of results, which are paginated. Once a page's results are exhausted, nextIterator() can go fetch the next page for iteration. This class, and accompanying test class are my original works. I have released them into the public domain, feel free to use the appropriate ASF license. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-396) New DynamicIterator class.
[ https://issues.apache.org/jira/browse/COLLECTIONS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587391#comment-13587391 ] Jeff Rodriguez commented on COLLECTIONS-396: Sounds good, Thomas. Attached updated copies. Thanks New DynamicIterator class. -- Key: COLLECTIONS-396 URL: https://issues.apache.org/jira/browse/COLLECTIONS-396 Project: Commons Collections Issue Type: New Feature Components: Iterator Environment: Java 1.5 or greater Reporter: Jeff Rodriguez Priority: Minor Labels: dynamic, iterator, new Attachments: LazyIteratorChain.java, LazyIteratorChainTest.java Original Estimate: 1h Remaining Estimate: 1h I would like to submit my DynamicIterator class for inclusion in Commons Collections. Description from JavaDoc: Iterates over the elements of an inner iterator provided by nextIterator() Once the inner iterator's hasNext() method returns false, nextIterator() will be called to obtain another iterator, and so on until nextIterator() returns null. The use case I had in mind for this class was the paged web service. A web service returns a list of results, which are paginated. Once a page's results are exhausted, nextIterator() can go fetch the next page for iteration. This class, and accompanying test class are my original works. I have released them into the public domain, feel free to use the appropriate ASF license. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587392#comment-13587392 ] Olivier Lamy (*$^¨%`£) commented on CLI-232: doh 1.3 is not released yet. 1.2 is the last one. btw fixed. Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587404#comment-13587404 ] Thomas Neidhart commented on CLI-232: - this was my fault, I did already prepare for the release to come. Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved CLI-232. - Resolution: Fixed Resolved issue, but did not assign a fix version as it is only related to the site. Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened CLI-232: -- The download for CGI is now OK, but there are several others that aren't working: collections el exec functor jelly jxpath (missing cgi file) launcher (missing) logging modeler (missing) net pool2 primitives (missing) transaction (missing) Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OGNL-231) Website: missing Download link; broken Benchmarks link
Sebb created OGNL-231: - Summary: Website: missing Download link; broken Benchmarks link Key: OGNL-231 URL: https://issues.apache.org/jira/browse/OGNL-231 Project: Commons OGNL Issue Type: Bug Reporter: Sebb There does not appear to be a Download link anywhere on the site. Also the Benchmarks link - http://commons.apache.org/proper/commons-ognl/benchmark.html - is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROXY-19) Website: missing Download link
Sebb created PROXY-19: - Summary: Website: missing Download link Key: PROXY-19 URL: https://issues.apache.org/jira/browse/PROXY-19 Project: Commons Proxy Issue Type: Bug Reporter: Sebb There does not appear to be a download link anyhere on the website -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587495#comment-13587495
]
Mirko Raner commented on CODEC-158:
---
It seems like everybody had a chance to voice their opinion on this feature
now. I'm not too familiar with how decisions are made at Apache Commons, so my
next question is how we drive this forward. I'm happy to accept any outcome
here, but to me it seems that this issue has been in limbo for long enough now.
Is there any other information I can provide to resolve this?
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Attachments: CODEC-158.patch, CODEC-158.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587506#comment-13587506
]
Gary Gregory commented on CODEC-158:
For me, fiddling with interfaces should be done in the context of dealing with
generics. It does not have to be that way of course, that's my opinion, but I
think that rejiggering the interfaces will make adding generics later more
painful. I could be wrong ;)
Please see the branch I created here:
https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Attachments: CODEC-158.patch, CODEC-158.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587505#comment-13587505
]
Gary Gregory commented on CODEC-158:
For me, fiddling with interfaces should be done in the context of dealing with
generics. It does not have to be that way of course, that's my opinion, but I
think that rejiggering the interfaces will make adding generics later more
painful. I could be wrong ;)
Please see the branch I created here:
https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Attachments: CODEC-158.patch, CODEC-158.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CODEC-158:
---
Comment: was deleted
(was: For me, fiddling with interfaces should be done in the context of dealing
with generics. It does not have to be that way of course, that's my opinion,
but I think that rejiggering the interfaces will make adding generics later
more painful. I could be wrong ;)
Please see the branch I created here:
https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics)
Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
and decoder
---
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Attachments: CODEC-158.patch, CODEC-158.patch
Original Estimate: 1h
Remaining Estimate: 1h
Currently, there are no common interfaces that extend both the encoder and
the decoder interfaces. This makes it hard to deal with a codec as a single
entity and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or
URLCodec. Because of the lack of a common superinterface they need to be
specified separately. There are some classes like BaseNCodec that can be used
to unify some of the encoders and decoders, but they are too specific and
restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement
that Codec interface, this could be directly bound to a combined
encoder/decoder implementation.
It would be nice if these interfaces were added and the existing codec
classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
modified to implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587508#comment-13587508 ] Olivier Lamy (*$^¨%`£) commented on CLI-232: ok will fix that. those files were added manually ? Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-527) clearPropertyDirect() in AbstractConfiguration should be abstract
[ https://issues.apache.org/jira/browse/CONFIGURATION-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587517#comment-13587517 ] Oliver Heger commented on CONFIGURATION-527: IIRC, backwards compatibility as mentioned by Jörg was the reason why it was implemented that way. We are currently working on version 2.0 which will break binary compatibility, so the patch can be applied. clearPropertyDirect() in AbstractConfiguration should be abstract - Key: CONFIGURATION-527 URL: https://issues.apache.org/jira/browse/CONFIGURATION-527 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.9 Reporter: Matthias Richter Priority: Minor Attachments: patch.diff The method clearPropertyDirect() in AbstractConfiguration has an empty implementation body. It is documented as should be overwritten but is not marked abstract. It should be abstract to prevent errors when subclassing AbstractConfiguration and using the clear() method where (indirectly) clearPropertyDirect() is being called. See addPropertyDirect() for comparison, which is abstract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-231) Website: missing Download link; broken Benchmarks link
[ https://issues.apache.org/jira/browse/OGNL-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587532#comment-13587532 ] Lukasz Lenart commented on OGNL-231: OGNL 4 wasn't released officially as a non-incubating project. Website: missing Download link; broken Benchmarks link -- Key: OGNL-231 URL: https://issues.apache.org/jira/browse/OGNL-231 Project: Commons OGNL Issue Type: Bug Reporter: Sebb There does not appear to be a Download link anywhere on the site. Also the Benchmarks link - http://commons.apache.org/proper/commons-ognl/benchmark.html - is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587538#comment-13587538 ] Olivier Lamy (*$^¨%`£) commented on CLI-232: proxy too. Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBUTILS-95) Remove all of the deprecated code
[ https://issues.apache.org/jira/browse/DBUTILS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-95. -- Resolution: Fixed Assignee: William R. Speirs Deprecated code removed in r1449890 Remove all of the deprecated code - Key: DBUTILS-95 URL: https://issues.apache.org/jira/browse/DBUTILS-95 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: Stevo Slavic Assignee: William R. Speirs Fix For: 2.0 There's some deprecated code in the project. All of it should be removed for good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-104) Add support for calling stored procs with return values
[ https://issues.apache.org/jira/browse/DBUTILS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-104: -- Affects Version/s: 2.0 Add support for calling stored procs with return values --- Key: DBUTILS-104 URL: https://issues.apache.org/jira/browse/DBUTILS-104 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0, 1.6 Reporter: William R. Speirs Assignee: William R. Speirs Calling stored procs can have both return values (usually only an integer) and out parameters. Currently QueryRunner doesn't handle return values making it impossible to call these types of stored procs. Add functionality for handling sotred procs that return values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-105) Add Named Parameter Support
[ https://issues.apache.org/jira/browse/DBUTILS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated DBUTILS-105: -- Affects Version/s: (was: 1.6) 2.0 Add Named Parameter Support --- Key: DBUTILS-105 URL: https://issues.apache.org/jira/browse/DBUTILS-105 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor It's 2013 (don't read before 2013) and we should have the ability to used named params instead of just position params. Because Oracle uses colon for something or another, we should handle both #param and :param. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-105) Add Named Parameter Support
[ https://issues.apache.org/jira/browse/DBUTILS-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587572#comment-13587572 ] William R. Speirs commented on DBUTILS-105: --- Named params were added in r1450009 (and subsequent revisions: r1450376). Please take a look at my implementation and provide feedback: http://svn.apache.org/viewvc/commons/proper/dbutils/branches/2_0/ Thanks in advance... Add Named Parameter Support --- Key: DBUTILS-105 URL: https://issues.apache.org/jira/browse/DBUTILS-105 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor It's 2013 (don't read before 2013) and we should have the ability to used named params instead of just position params. Because Oracle uses colon for something or another, we should handle both #param and :param. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-445) Several unit test failures with IBM JDK 6
Thomas Neidhart created COLLECTIONS-445: --- Summary: Several unit test failures with IBM JDK 6 Key: COLLECTIONS-445 URL: https://issues.apache.org/jira/browse/COLLECTIONS-445 Project: Commons Collections Issue Type: Bug Reporter: Thomas Neidhart -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-95) Remove all of the deprecated code
[ https://issues.apache.org/jira/browse/DBUTILS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587576#comment-13587576 ] Simone Tripodi commented on DBUTILS-95: --- Very well played Bill! I noticed the commits list, congratulations and thanks for the hard work! I will try to have a look at it ASAP, I am currently in Switzerland for work and have a lot of work to do... hope to get back to you very soon! Is it already time to call for a new release? All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Feb 26, 2013 at 10:16 PM, William R. Speirs (JIRA) Remove all of the deprecated code - Key: DBUTILS-95 URL: https://issues.apache.org/jira/browse/DBUTILS-95 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 2.0 Reporter: Stevo Slavic Assignee: William R. Speirs Fix For: 2.0 There's some deprecated code in the project. All of it should be removed for good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DBUTILS-99) Create QueryRunner Factory
[ https://issues.apache.org/jira/browse/DBUTILS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs closed DBUTILS-99. Create QueryRunner Factory -- Key: DBUTILS-99 URL: https://issues.apache.org/jira/browse/DBUTILS-99 Project: Commons DbUtils Issue Type: Improvement Affects Versions: 1.5 Reporter: William R. Speirs Assignee: William R. Speirs Priority: Minor Fix For: 1.5 Currently there is no good way to use dependency injection with QueryRunners. Creating a simple factory class to allow for easy injection (and therefore easier unit test creation) should solve this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-231) Website: missing Download link; broken Benchmarks link
[ https://issues.apache.org/jira/browse/OGNL-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587636#comment-13587636 ] Sebb commented on OGNL-231: --- If it has not been released, this should be noted on the website. One way to do this is on a download page, which can then later be updated with an actual release. Since common proper are all supposed to be released, it helps if they all have a Download page Website: missing Download link; broken Benchmarks link -- Key: OGNL-231 URL: https://issues.apache.org/jira/browse/OGNL-231 Project: Commons OGNL Issue Type: Bug Reporter: Sebb There does not appear to be a Download link anywhere on the site. Also the Benchmarks link - http://commons.apache.org/proper/commons-ognl/benchmark.html - is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-232) Download link gives HTTP/1.1 403 Forbidden
[ https://issues.apache.org/jira/browse/CLI-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587754#comment-13587754 ] Olivier Lamy (*$^¨%`£) commented on CLI-232: still an issue for functor I will review later Download link gives HTTP/1.1 403 Forbidden -- Key: CLI-232 URL: https://issues.apache.org/jira/browse/CLI-232 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.2 Environment: Firefox 10.0.4 and curl 7.19.0 (sparc-sun-solaris2.10) libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.5 libidn/1.10 Reporter: michael tibbetts Clicking on the Download link in the left hand menu under Commons CLI header directs to http://commons.apache.org/proper/commons-cli/download_cli.cgi Accessing the link yeilds a 403 Forbidden -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
