[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-tabpanel&focusedCommentId=13593207#comment-13593207
]
Jean-Marc Borer edited comment on VFS-467 at 3/5/13 7:54 AM:
-
What do you mean by reference? I know that my fix might not cover all cases,
that is why I did not send a patch yet. I have still to write unit tests.
However what is sure is that the test is wrong: it doesn't compare similar
things (relative against absolute paths). As I had not enough time to study the
VFS code, I hoped someone with a better understanding would react to my
proposed solution. It is a simple fix otherwise I had to touch much more code
and potentially break more things.
was (Author: jmborer):
What do you mean by reference? I know that my fix might not cover all
cases, that is why I did not send a patch yet. I have still to write unit
tests.
However what is sure is that the test is wrong: it doesn't compare similar
things (relative against absolute). As I had not enough time to study the VFS
code, I hoped someone with a better understanding would react to my proposed
solution...
> 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] [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-tabpanel&focusedCommentId=13593207#comment-13593207
]
Jean-Marc Borer edited comment on VFS-467 at 3/5/13 7:53 AM:
-
What do you mean by reference? I know that my fix might not cover all cases,
that is why I did not send a patch yet. I have still to write unit tests.
However what is sure is that the test is wrong: it doesn't compare similar
things (relative against absolute). As I had not enough time to study the VFS
code, I hoped someone with a better understanding would react to my proposed
solution...
was (Author: jmborer):
What do you mean by reference. I know that my fix might not cover all
cases, that is why I did not send a patch yet. I have still to write unit
tests.
However what is sure is that the test is wrong: it doesn't compare similar
things (relative against absolute). As I had not enough time to study the VFS
code, I hoped someone with a better understanding would react to my proposed
solution...
> 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] [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-tabpanel&focusedCommentId=13593207#comment-13593207
]
Jean-Marc Borer commented on VFS-467:
-
What do you mean by reference. I know that my fix might not cover all cases,
that is why I did not send a patch yet. I have still to write unit tests.
However what is sure is that the test is wrong: it doesn't compare similar
things (relative against absolute). As I had not enough time to study the VFS
code, I hoped someone with a better understanding would react to my proposed
solution...
> 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] [Commented] (COMPRESS-220) createCompressorInputStream with decompressConcatenated option
[ https://issues.apache.org/jira/browse/COMPRESS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593086#comment-13593086 ] Stefan Bodewig commented on COMPRESS-220: - Yes, sounds like a good idea to enable something like this. ArchiveStreamFactory has a setter for entry-encoding at the factory level, might be good to mirror this for the decompressConcatenated flag in CompressorStreamFactory. > createCompressorInputStream with decompressConcatenated option > -- > > Key: COMPRESS-220 > URL: https://issues.apache.org/jira/browse/COMPRESS-220 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Affects Versions: 1.4.1 >Reporter: Gregory Chanan >Priority: Minor > Fix For: 1.5 > > > I want to use CompressorStreamFactory.createCompressorInputStream to detect > the compressor type for me and return the correct stream type, but I also > want the stream to have decompressConcatenated turned on. > I can check the type of the stream returned to me, use the two-arg > constructor for that type and throw the original returned object away, but it > would be simpler if there were either additional functions to do this for me > in CompressorStreamFactory, i.e.: > createCompressorInputStream(final InputStream in, boolean > decompressConcatenated) > createCompressorInputStream(final String name, final InputStream in, boolean > decompressConcatenated) > or through another Factory method, e.g. CompressorConcatStreamFactory. > Thoughts? -- 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] (COMPRESS-220) createCompressorInputStream with decompressConcatenated option
[ https://issues.apache.org/jira/browse/COMPRESS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-220: Fix Version/s: 1.5 > createCompressorInputStream with decompressConcatenated option > -- > > Key: COMPRESS-220 > URL: https://issues.apache.org/jira/browse/COMPRESS-220 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Affects Versions: 1.4.1 >Reporter: Gregory Chanan >Priority: Minor > Fix For: 1.5 > > > I want to use CompressorStreamFactory.createCompressorInputStream to detect > the compressor type for me and return the correct stream type, but I also > want the stream to have decompressConcatenated turned on. > I can check the type of the stream returned to me, use the two-arg > constructor for that type and throw the original returned object away, but it > would be simpler if there were either additional functions to do this for me > in CompressorStreamFactory, i.e.: > createCompressorInputStream(final InputStream in, boolean > decompressConcatenated) > createCompressorInputStream(final String name, final InputStream in, boolean > decompressConcatenated) > or through another Factory method, e.g. CompressorConcatStreamFactory. > Thoughts? -- 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] (COMPRESS-199) Introduction of XZ breaks OSGi support
[ https://issues.apache.org/jira/browse/COMPRESS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593081#comment-13593081 ] Stefan Bodewig commented on COMPRESS-199: - As far as I understand it, yes. The dependency is marked optional so it should be possible to use Compress in an OSGi context without XZ being present. > Introduction of XZ breaks OSGi support > -- > > Key: COMPRESS-199 > URL: https://issues.apache.org/jira/browse/COMPRESS-199 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.4.1 > Environment: Windows Vista & RHEL 6.2, Java 1.6.0_33, Equinox > org.eclipse.osgi_3.7.2.v20120110-1415.jar. >Reporter: Niklas Gertoft > Labels: osgi > Fix For: 1.5 > > > The introduction of XZ seems to break the OSGi support for the compress > bundle. > The XZ component doesn't seem to be included or referred to (dependency). > !ENTRY org.apache.commons.compress 4 0 2012-08-20 17:06:19.339 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: The bundle > "org.apache.commons.compress_1.4.1 [20]" could not be resolved. Reason: > Missing Constraint: Import-Package: org.tukaani.xz; version="0.0.0" > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389) > at > org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Included in my project by maven and > > org.apache.commons > commons-compress > 1.4.1 > -- 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] (COMPRESS-199) Introduction of XZ breaks OSGi support
[ https://issues.apache.org/jira/browse/COMPRESS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592930#comment-13592930 ] Matt Quigley commented on COMPRESS-199: --- So will we be able to use Compress _without_ XZ after this patch is applied? This is unnecessarily bloating my Android project, which does _not_ need XZ support but Compress crashes when the xz-lib is not bundled. > Introduction of XZ breaks OSGi support > -- > > Key: COMPRESS-199 > URL: https://issues.apache.org/jira/browse/COMPRESS-199 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.4.1 > Environment: Windows Vista & RHEL 6.2, Java 1.6.0_33, Equinox > org.eclipse.osgi_3.7.2.v20120110-1415.jar. >Reporter: Niklas Gertoft > Labels: osgi > Fix For: 1.5 > > > The introduction of XZ seems to break the OSGi support for the compress > bundle. > The XZ component doesn't seem to be included or referred to (dependency). > !ENTRY org.apache.commons.compress 4 0 2012-08-20 17:06:19.339 > !MESSAGE FrameworkEvent ERROR > !STACK 0 > org.osgi.framework.BundleException: The bundle > "org.apache.commons.compress_1.4.1 [20]" could not be resolved. Reason: > Missing Constraint: Import-Package: org.tukaani.xz; version="0.0.0" > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1327) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1311) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389) > at > org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) > Included in my project by maven and > > org.apache.commons > commons-compress > 1.4.1 > -- 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] (COMPRESS-220) createCompressorInputStream with decompressConcatenated option
Gregory Chanan created COMPRESS-220: --- Summary: createCompressorInputStream with decompressConcatenated option Key: COMPRESS-220 URL: https://issues.apache.org/jira/browse/COMPRESS-220 Project: Commons Compress Issue Type: Improvement Components: Compressors Affects Versions: 1.4.1 Reporter: Gregory Chanan Priority: Minor I want to use CompressorStreamFactory.createCompressorInputStream to detect the compressor type for me and return the correct stream type, but I also want the stream to have decompressConcatenated turned on. I can check the type of the stream returned to me, use the two-arg constructor for that type and throw the original returned object away, but it would be simpler if there were either additional functions to do this for me in CompressorStreamFactory, i.e.: createCompressorInputStream(final InputStream in, boolean decompressConcatenated) createCompressorInputStream(final String name, final InputStream in, boolean decompressConcatenated) or through another Factory method, e.g. CompressorConcatStreamFactory. Thoughts? -- 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-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592633#comment-13592633
]
Thomas Vahrst commented on COLLECTIONS-310:
---
SetUniqueListTest.java now contains some new testcases to test the behavior of
listiterators of sublists.
SetUniqueList.v2.java is the 2nd variant I implemented. In contrast to the
first attempt, this class does not inherit from AbstractListDecorator but
inherits from java.util.AbstractList. It holds a reference to a underlying list
which is *shared* with all sublists. So every sublist holds the reference to
the underlying list and maintains it's own set and a offset of its element
range in the underlying list.
This variant contains support for iterators and listiterators on sublists.
I personally found this solution a bit more elegant than the first variant.
> Modifications of a SetUniqueList.subList() invalidate the parent list
> -
>
> Key: COLLECTIONS-310
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
> Project: Commons Collections
> Issue Type: Bug
> Components: List
>Affects Versions: 3.2, Nightly Builds
>Reporter: Christian Semrau
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SetUniqueList.java, SetUniqueList.patch,
> SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java
>
>
> The List returned by SetUniqueList.subList() is again a SetUniqueList. The
> contract for List.subList() says that the returned list supports all the
> operations of the parent list, and it is backed by the parent list.
> We have a SetUniqueList uniqueList equal to {"Hello", "World"}. We get a
> subList containing the last element. Now we add the element "Hello",
> contained in the uniqueList but not in the subList, to the subList.
> What should happen?
> Should the subList behave like a SetUniqueList and add the element - meaning
> that it changes position in the uniqueList because at the old place it gets
> removed, so now uniqueList equals {"World", "Hello"} (which fails)?
> Or should the element not be added, because it is already contained in the
> parent list, thereby violating the SetUniqueList-ness of the subList (which
> fails)?
> I prefer the former behaviour, because modifications should only be made
> through the subList and not through the parent list (as explained in
> List.subList()).
> What should happen if we replace (using set) the subList element "World" with
> "Hello" instead of adding an element?
> The subList should contain only "Hello", and for the parent list, the old
> element 0 (now a duplicate of the just set element 1) should be removed
> (which fails).
> And of course the parent list should know what happens to it (specifically,
> its uniqueness Set) (which fails in the current snapshot).
> public void testSubListAddNew() {
> List uniqueList = SetUniqueList.decorate(new ArrayList());
> uniqueList.add("Hello");
> uniqueList.add("World");
> List subList = uniqueList.subList(1, 2);
> subList.add("Goodbye");
> List expectedSubList = Arrays.asList(new Object[] { "World",
> "Goodbye" });
> List expectedParentList = Arrays.asList(new Object[] { "Hello",
> "World", "Goodbye" });
> assertEquals(expectedSubList, subList);
> assertEquals(expectedParentList, uniqueList);
> assertTrue(uniqueList.contains("Goodbye")); // fails
> }
> public void testSubListAddDuplicate() {
> List uniqueList = SetUniqueList.decorate(new ArrayList());
> uniqueList.add("Hello");
> uniqueList.add("World");
> List subList = uniqueList.subList(1, 2);
> subList.add("Hello");
> List expectedSubList = Arrays.asList(new Object[] { "World",
> "Hello" });
> List expectedParentList = Arrays.asList(new Object[] { "World",
> "Hello" });
> assertEquals(expectedSubList, subList);
> assertEquals(expectedParentList, uniqueList); // fails
> }
> public void testSubListSetDuplicate() {
> List uniqueList = SetUniqueList.decorate(new ArrayList());
> uniqueList.add("Hello");
> uniqueList.add("World");
> List subList = uniqueList.subList(1, 2);
> subList.set(0, "Hello");
> List expectedSubList = Arrays.asList(new Object[] { "Hello" });
> List expectedParentList = Arrays.asList(new Object[] { "Hello"
> });
> assertEquals(expectedSubList, subList);
> assertEquals(expectedParentList, uniqueList); // fails
> }
--
This m
[jira] [Commented] (CONFIGURATION-528) ConfigurationInterpolator class does not load if security manager enabled
[
https://issues.apache.org/jira/browse/CONFIGURATION-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592617#comment-13592617
]
Oliver Heger commented on CONFIGURATION-528:
We are currently working on version 2.0 of Commons Configuration, and there
have been some major changes, also in the area of interpolation. The problem
you describe is probably solved in the meantime.
{{ConfigurationInterpolator}} still instantiates default lookups in a static
block. However, {{EnvironmentLookup}} no longer uses
{{EnvironmentConfiguration}}; rather it queries the environment in its
{{lookup()}} method. So the security manager should only complain if
environment variables are acutally used for interpolation.
Is this solution okay for you or do you have another proposal?
> ConfigurationInterpolator class does not load if security manager enabled
> -
>
> Key: CONFIGURATION-528
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-528
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 1.9
>Reporter: Laurent Sauvage
>Priority: Minor
>
> ConfigurationInterpolator class does not load if security manager is enabled
> because its static initializer instantiate EnvironmentLookup which
> instantiate EnvironmentConfiguration which use System.getenv()in its
> constructor. But System.getenv() can fail if RuntimePermission("getenv.*") is
> not granted.
> Notice this "bug" is annoying to catch because a NoClassDefFoundError is
> thrown when classloading ConfigurationInterpolator without the good
> AccessControlException showing the real source of the 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] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vahrst updated COLLECTIONS-310:
--
Attachment: SetUniqueListTest.java
SetUniqueList.v2.java
2nd variant of modified SetUniqueList and even more Testcases für sublist.
> Modifications of a SetUniqueList.subList() invalidate the parent list
> -
>
> Key: COLLECTIONS-310
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
> Project: Commons Collections
> Issue Type: Bug
> Components: List
>Affects Versions: 3.2, Nightly Builds
>Reporter: Christian Semrau
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SetUniqueList.java, SetUniqueList.patch,
> SetUniqueListTest.java, SetUniqueListTest.java, SetUniqueList.v2.java
>
>
> The List returned by SetUniqueList.subList() is again a SetUniqueList. The
> contract for List.subList() says that the returned list supports all the
> operations of the parent list, and it is backed by the parent list.
> We have a SetUniqueList uniqueList equal to {"Hello", "World"}. We get a
> subList containing the last element. Now we add the element "Hello",
> contained in the uniqueList but not in the subList, to the subList.
> What should happen?
> Should the subList behave like a SetUniqueList and add the element - meaning
> that it changes position in the uniqueList because at the old place it gets
> removed, so now uniqueList equals {"World", "Hello"} (which fails)?
> Or should the element not be added, because it is already contained in the
> parent list, thereby violating the SetUniqueList-ness of the subList (which
> fails)?
> I prefer the former behaviour, because modifications should only be made
> through the subList and not through the parent list (as explained in
> List.subList()).
> What should happen if we replace (using set) the subList element "World" with
> "Hello" instead of adding an element?
> The subList should contain only "Hello", and for the parent list, the old
> element 0 (now a duplicate of the just set element 1) should be removed
> (which fails).
> And of course the parent list should know what happens to it (specifically,
> its uniqueness Set) (which fails in the current snapshot).
> public void testSubListAddNew() {
> List uniqueList = SetUniqueList.decorate(new ArrayList());
> uniqueList.add("Hello");
> uniqueList.add("World");
> List subList = uniqueList.subList(1, 2);
> subList.add("Goodbye");
> List expectedSubList = Arrays.asList(new Object[] { "World",
> "Goodbye" });
> List expectedParentList = Arrays.asList(new Object[] { "Hello",
> "World", "Goodbye" });
> assertEquals(expectedSubList, subList);
> assertEquals(expectedParentList, uniqueList);
> assertTrue(uniqueList.contains("Goodbye")); // fails
> }
> public void testSubListAddDuplicate() {
> List uniqueList = SetUniqueList.decorate(new ArrayList());
> uniqueList.add("Hello");
> uniqueList.add("World");
> List subList = uniqueList.subList(1, 2);
> subList.add("Hello");
> List expectedSubList = Arrays.asList(new Object[] { "World",
> "Hello" });
> List expectedParentList = Arrays.asList(new Object[] { "World",
> "Hello" });
> assertEquals(expectedSubList, subList);
> assertEquals(expectedParentList, uniqueList); // fails
> }
> public void testSubListSetDuplicate() {
> List uniqueList = SetUniqueList.decorate(new ArrayList());
> uniqueList.add("Hello");
> uniqueList.add("World");
> List subList = uniqueList.subList(1, 2);
> subList.set(0, "Hello");
> List expectedSubList = Arrays.asList(new Object[] { "Hello" });
> List expectedParentList = Arrays.asList(new Object[] { "Hello"
> });
> assertEquals(expectedSubList, subList);
> assertEquals(expectedParentList, uniqueList); // fails
> }
--
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] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list
[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580821#comment-13580821
]
Thomas Vahrst edited comment on COLLECTIONS-310 at 3/4/13 8:32 PM:
---
SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I
am not sure whether the patch has a correct format (I am not able to re-apply
the patch in Netbeans...) so I attached the corresponding java files as well.
Some comment to this solution:
1. During the implementation I recognized, that the existing implementation of
subList() uses the subList() method on the decorated list and then creates a
new Set and fills all elements of the sublist into the set.
Now this issue requires, that a parent list has to be modified on certain
invocations on a sublist - for example when adding an element to the sublist
which exists in the parent list somewhere outside the range of the sublist.
With the current sublist implementation, any attempt to modify a parent list
fails with a ConcurrentModifiationException. So we have to reimplement the
sublist functionality inside SetUniqueList and can not reuse the service of
AbstractListDecorator.
2. When we create a subList on a SetUniqueList, this sublist has to obbey the
SetUniqueList contracts. The original parent list will have slightly different
behavior when adding or setting values. When we create a second sublist based
on the first sublist, this top most list has to provide SetUniqueList semantics.
Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:
subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}
(The 'movement' of 'd' causes the ConcurrentModificationException mentioned
above.)
Because of this requirements I decided for Variant No. 1, that every
SetUniqueList holds its own list and set and maintains a reference to it's
parent SetUniqueList and an offset value. The SetUniqueList garantees, that all
parent lists are updated according to the required functionality and that all
offset values are adjusted if necessary. This solution does not use the sublist
functionality of the decorated list but creates allway a new Set *and* List.
I copied the existing code for creating a new Set to also create a new List
based on the existing list.
At this time, there are two things missing:
# a very details javadoc comment for the subList() method, explaining the
behavior.
# the implementation for listIterator().
... to be continued with variant no. 2 ...
was (Author: t.vahrst):
SetUniqueList.patch contains JUnit Tests and Variant No. 1 for
SetUniqueList. I am not sure whether the patch has a correct format (I am not
able to re-apply the patch in Netbeans...) so I attached the corresponding java
files as well.
Some comment to this solution:
1. During the implementation I recognized, that the existing implementation of
subList() uses the subList() method on the decorated list and then creates a
new Set and fills all elements of the sublist into the set.
Now this issue requires, that a parent list has to be modified on certain
invocations on a sublist - for example when adding an element to the sublist
which exists in the parent list somewhere outside the range of the sublist.
With the current sublist implementation, any attempt to modify a parent list
fails with a ConcurrentModifiationException. So we have to reimplement the
sublist functionality inside SetUniqueList and can not reuse the service of
AbstractListDecorator.
2. When we create a subList on a SetUniqueList, this sublist has to obbey the
SetUniqueList contracts. The original parent list will have slightly different
behavior when adding or setting values. When we create a second sublist based
on the first sublist, this top most list has to provide SetUniqueList semantics.
Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
Adds a 'd' to subLis
[jira] [Resolved] (COLLECTIONS-447) TreeListIterator can return incorrect results after remove() is called
[
https://issues.apache.org/jira/browse/COLLECTIONS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-447.
-
Resolution: Fixed
Fix Version/s: 4.0
Applied the patch together with some additional comment in r1452481.
Thanks for the analysis and patch, this was really a tricky one!
> TreeListIterator can return incorrect results after remove() is called
> --
>
> Key: COLLECTIONS-447
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-447
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: Nightly Builds
> Environment: Windows 7, jdk1.5.0_22
>Reporter: Jeffrey Barnes
> Labels: patch, test
> Fix For: 4.0
>
> Attachments: fix.patch, testcase.patch
>
>
> {{TreeList.TreeListIterator}} can get in a bad state when {{remove()}} is
> called, causing it to subsequently return incorrect results. This is because
> {{TreeListIterator}} caches an {{AVLNode}} reference in its field {{next}},
> and this node reference may become stale when {{remove()}} is called (it may
> contain a reference to a node that no longer exists in the tree).
> I will attach two patches: {{testcase.patch}} will contain a test case
> illustrating the bug, and {{fix.patch}} will contain a fix. (To fix the bug,
> I simply clear the cached {{next}} value in {{TreeListIterator.remove}}.)
> This was originally reported in a comment to COLLECTIONS-433; I am creating a
> separate issue for this at Thomas Neidhart's suggestion.
--
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-tabpanel&focusedCommentId=13592350#comment-13592350
]
Joerg Schaible commented on VFS-467:
Can you give a reference to support your assumption about the relative paths in
WebDAV?
> 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] [Resolved] (VFS-469) [WebDAV] Dependency javax.jrc:jcr is not used
[ https://issues.apache.org/jira/browse/VFS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved VFS-469. Resolution: Fixed commit -m "Remove unused dependency to javax.jcr:jcr (VFS-469)." Sendingcore/pom.xml Sendingpom.xml Sendingsrc/changes/changes.xml Transmitting file data ... Committed revision 1452370. > [WebDAV] Dependency javax.jrc:jcr is not used > - > > Key: VFS-469 > URL: https://issues.apache.org/jira/browse/VFS-469 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Joerg Schaible >Assignee: Joerg Schaible >Priority: Minor > Fix For: 2.1 > > > The WebDAV provider does not make use of the dependency to javax.jcr:jcr nor > does the test provider. -- 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-469) [WebDAV] Dependency javax.jrc:jcr is not used
Joerg Schaible created VFS-469: -- Summary: [WebDAV] Dependency javax.jrc:jcr is not used Key: VFS-469 URL: https://issues.apache.org/jira/browse/VFS-469 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Joerg Schaible Assignee: Joerg Schaible Priority: Minor Fix For: 2.1 The WebDAV provider does not make use of the dependency to javax.jcr:jcr nor does the test provider. -- 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] (BEANUTILS-430) Clean up SVN keywords
Benedikt Ritter created BEANUTILS-430: - Summary: Clean up SVN keywords Key: BEANUTILS-430 URL: https://issues.apache.org/jira/browse/BEANUTILS-430 Project: Commons BeanUtils Issue Type: Improvement Affects Versions: 1.8.3 Reporter: Benedikt Ritter Fix For: 1.8.4 For example a lot of files contain the $Date$ keyword. This should not be used because it depends on the clients locale. -- 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
