[jira] [Created] (LANG-869) add randomXMLText
Jin Kwon created LANG-869:
-
Summary: add randomXMLText
Key: LANG-869
URL: https://issues.apache.org/jira/browse/LANG-869
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Reporter: Jin Kwon
Priority: Trivial
Please add some random method for values of XML elements or attributes.
I tried RandomStringUtils#random() for XML tag values and got
{{An invalid XML character (Unicode: 0x11) was found in the element content of
the document.}}
#randomAxxx and #randomNxxx may not enough.
Thanks.
--
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] (MATH-817) Multivariate Normal Mixture Model Fitting by Expectation Maximization
[
https://issues.apache.org/jira/browse/MATH-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13574052#comment-13574052
]
Jared Becksfort commented on MATH-817:
--
{quote}
A typical example would be the number of components which the fitted mixture
should contain. Is it a parameter to be fixed at the fitter's construction?
{quote}
I think it will be best to supply data to the constructor and fitting
parameters to the fit method. This would allow one object to fit the same data
with different numbers of components or initial means. The data will be the
large part, so it is probably best to initialize it once and allow the user to
fit it multiple times with varying parameters without reconstructing an object.
That is how I will do it unless there is an objection.
> Multivariate Normal Mixture Model Fitting by Expectation Maximization
> -
>
> Key: MATH-817
> URL: https://issues.apache.org/jira/browse/MATH-817
> Project: Commons Math
> Issue Type: New Feature
>Reporter: Jared Becksfort
>Priority: Minor
> Attachments: AbstractMultivariateRealDistribution.java.patch,
> MixtureMultivariateRealDistribution.java.patch,
> MultivariateNormalDistribution.java.patch,
> MultivariateNormalMixtureExpectationMaximizationFitter.java,
> MultivariateNormalMixtureExpectationMaximizationFitterTest.java
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> I will submit a class for fitting Multivariate Normal Mixture Models using
> Expectation Maximization.
> > Hello,
> >
> > I have implemented some classes for multivariate Normal distributions,
> > multivariate normal mixture models, and an expectation maximization fitting
> > class for the mixture model. I would like to submit it to Apache Commons
> > Math. I still have some touching up to do so that they fit the style
> > guidelines and implement the correct interfaces. Before I do so, I thought
> > I would at least ask if the developers of the project are interested in me
> > submitting them.
> >
> > Thanks,
> > Jared Becksfort
> Dear Jared,
> Yes, that would be very nice to have such an addition! Remember to also
> include unit tests (refer to the current ones for examples). The best would
> be to split a submission up into multiple minor ones, each covering a natural
> submission (e.g. multivariate Normal distribution in one submission), and
> create an issue as described at
> http://commons.apache.org/math/issue-tracking.html .
> If you run into any problems, please do not hesitate to ask on this mailing
> list.
> Cheers, Mikkel.
--
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] (NET-501) Race Condition on TelnetClient.disconnect() and TelnetInputStream.run() . java.lang.IllegalStateException: Queue is full! Cannot process another character.
[
https://issues.apache.org/jira/browse/NET-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julián Lastiri updated NET-501:
---
Description:
I'm getting the following exception while disconnecting a threaded
(readerThread=true) TelnetClient connection.
Exception in thread "Thread-160" java.lang.IllegalStateException: Queue is
full! Cannot process another character.
at
org.apache.commons.net.telnet.TelnetInputStream.__processChar(TelnetInputStream.java:339)
at
org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:647)
at java.lang.Thread.run(Thread.java:722)
I noticed that when TelnetClient.disconnect() is called the attribute
__threaded is set to false while the thread in the TelnetInputStream.run()
method could call TelnetInputStream().__processChar(...) throwing
IllegalStateException
This is a test program to reproduce the issue
public class TestTelnetClient implements Runnable {
/**
* @param args
*/
public static void main(String[] args) {
ArrayList workers = new ArrayList();
for( int i=0; i<1000; ++i){
Thread t = new Thread ( new TestTelnetClient() );
t.start();
workers.add(t);
}
for (Thread t : workers ) {
try {
t.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
@Override
public void run() {
System.out.println("Starting thread...");
TelnetClient tc = new TelnetClient();
// tc.setReaderThread(false);
try {
tc.connect("localhost", 23);
tc.setSoTimeout(1000);
InputStream in = tc.getInputStream();
int ch;
in.read();
} catch (SocketException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
System.out.println("Disconnecting...");
try {
tc.disconnect();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
A telnet server (telnetd) is required. I also modified the initial banner (
/etc/issue.net ) with a lot of characters to get a better chance to receive
information while calling disconnect.
was:
I'm getting the following exception while disconnecting a threaded
(readerThread=true) TelnetClient connection.
Exception in thread "Thread-160" java.lang.IllegalStateException: Queue is
full! Cannot process another character.
at
org.apache.commons.net.telnet.TelnetInputStream.__processChar(TelnetInputStream.java:339)
at
org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:647)
at java.lang.Thread.run(Thread.java:722)
I noticed that when TelnetClient.disconnect() is called the attribute
__threaded is set to false while the thread in the TelnetInputStream.run()
method could call TelnetInputStream().__processChar(...) throwing
IllegalStateException
> Race Condition on TelnetClient.disconnect() and TelnetInputStream.run() .
> java.lang.IllegalStateException: Queue is full! Cannot process another
> character.
> ---
>
> Key: NET-501
> URL: https://issues.apache.org/jira/browse/NET-501
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
>Affects Versions: 3.2
> Environment: Ubuntu 12.04 64 bits x86
>Reporter: Julián Lastiri
>
> I'm getting the following exception while disconnecting a threaded
> (readerThread=true) TelnetClient connection.
> Exception in thread "Thread-160" java.lang.IllegalStateException: Queue is
> full! Cannot process another character.
> at
> org.apache.commons.net.telnet.TelnetInputStream.__processChar(TelnetInputStream.java:339)
> at
> org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:647)
> at java.lang.Thread.run(Thread.java:722)
> I noticed that when TelnetClient.disconnect() is called the attribute
> __threaded is set to false while the thread in the TelnetInputStream.run()
> method could call TelnetInputStream
[jira] [Created] (NET-501) Race Condition on TelnetClient.disconnect() and TelnetInputStream.run() . java.lang.IllegalStateException: Queue is full! Cannot process another character.
Julián Lastiri created NET-501: -- Summary: Race Condition on TelnetClient.disconnect() and TelnetInputStream.run() . java.lang.IllegalStateException: Queue is full! Cannot process another character. Key: NET-501 URL: https://issues.apache.org/jira/browse/NET-501 Project: Commons Net Issue Type: Bug Components: Telnet Affects Versions: 3.2 Environment: Ubuntu 12.04 64 bits x86 Reporter: Julián Lastiri I'm getting the following exception while disconnecting a threaded (readerThread=true) TelnetClient connection. Exception in thread "Thread-160" java.lang.IllegalStateException: Queue is full! Cannot process another character. at org.apache.commons.net.telnet.TelnetInputStream.__processChar(TelnetInputStream.java:339) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:647) at java.lang.Thread.run(Thread.java:722) I noticed that when TelnetClient.disconnect() is called the attribute __threaded is set to false while the thread in the TelnetInputStream.run() method could call TelnetInputStream().__processChar(...) throwing IllegalStateException -- 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-374) Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test
[
https://issues.apache.org/jira/browse/COLLECTIONS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573750#comment-13573750
]
Thomas Neidhart commented on COLLECTIONS-374:
-
The first test is not relevant anymore, as BeanMap has been removed.
The second test checks symmetry of equals for the following scenario:
{noformat}
v1 = BoundedFifoBuffer
v2 = TransformedBuffer(v1)
v3 = UnmodifiableBuffer(v2)
v2 == v3 && v3 == v2
{noformat}
this fails because of AbstractCollectionDecorate#equals:
{noformat}
return object == this || decorated().equals(object);
{noformat}
now v3.equals(v2) evaluates to true, as v3.decorated() == v2
the other way round, v2.equals(v3) if false, as v2.decorated() == v1, and v1
does not implement equals, thus the default Object.equals() is used, which just
compares references.
> Bug in class#BeanMap and TransformedBuffer with reproducible JUnit test
> ---
>
> Key: COLLECTIONS-374
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-374
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: jdk 1.6.0
>Reporter: Sai Zhang
> Attachments: ApacheCommons_Documented_Test.java
>
>
> Hi all:
> (as in the previous post)
> I am writing an automated bug finding tool, and using
> Apache Commons Collections as an experimental subject
> for evaluation.
> The tool creates executable JUnit tests as well as
> explanatory code comments. I attached one bug-revealing
> test as follows. Could you please kindly check it, to
> see if it is a real bug or not?
> Also, it would be tremendous helpful if you could give
> some feedback and suggestion on the generated code comments?
> From the perspective of developers who are relatively familiar
> with the code,
> is the automatically-inferred comment useful in understanding
> the generated test? is the comment helpful in bug fixing?
> Your suggestion will help us improve the tool.
> Please see attachment for the failed test.
> The comment appears in the form of:
> //Tests pass if (it gives some small change to the test which can make
> the failed test pass)
--
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-419) Performance problem in AbstractDualBidiMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-419: Issue Type: Improvement (was: Bug) > Performance problem in AbstractDualBidiMap > -- > > Key: COLLECTIONS-419 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-419 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2.1 > Environment: java 1.6.0_24 > Ubuntu 11.10 >Reporter: Adrian Nistor > Attachments: patch.diff, Test.java > > > Hi, > I am encountering a performance problem in AbstractDualBidiMap. It > appears in version 3.2.1 and also in revision 1355448. I attached a > test that exposes this problem and a one-line patch that fixes it. On > my machine, for this test, the patch provides a 130X speedup. > To run the test, just do: > $ java Test > The output for the un-patched version is: > Time is 5460 > The output for the patched version is: > Time is 42 > The attached test shows that, for a "DualHashBidiMap bidi" object, the > following operation is very slow: > bidi.keySet().retainAll(toRetain) > DualHashBidiMap.keySet() returns a "DualHashBidiMap.KeySet" object, > which inherits "retainAll(Collection coll)" from > "AbstractDualBidiMap.View". Similarly, > bidi.values().retainAll(toRetain) > bidi.entrySet().retainAll(toRetain) > are also slow. This happens for both DualHashBidiMap and > DualTreeBidiMap, which extend AbstractDualBidiMap. > As the patch shows, the problem is that > "AbstractDualBidiMap.View.retainAll(Collection coll)" performs > "coll.contains(it.next())" for each element in the View. > "coll.contains(it.next())" can be very slow, e.g., if "coll" is a > list. > The one-line patch I attached puts the elements of "coll" in a HashSet > (which has very fast "contains()"), if "coll" is not already a set: > "if (!(coll instanceof Set)) coll = new java.util.HashSet(coll);" > Is this a bug, or am I misunderstanding the intended behavior? If so, > can you please confirm that the patch is correct? > Thanks, > Adrian -- 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-433) TreeList.addAll() complexity
[ https://issues.apache.org/jira/browse/COLLECTIONS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-433: Issue Type: Improvement (was: Bug) > TreeList.addAll() complexity > > > Key: COLLECTIONS-433 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-433 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Adrian Nistor > > "TreeList.addAll(Collection coll)" has a higher complexity than > necessary when "coll" is a "TreeList" object (because "addAll" just > adds one element at a time). This can be done in just O(N) as > described for example here: > http://stackoverflow.com/questions/4458489/merging-2-diferent-avl-trees > Are there any plans to improve this? -- 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-434) performance problem in CursorableLinkedList.containsAll()
[
https://issues.apache.org/jira/browse/COLLECTIONS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated COLLECTIONS-434:
Issue Type: Improvement (was: Bug)
> performance problem in CursorableLinkedList.containsAll()
> -
>
> Key: COLLECTIONS-434
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-434
> Project: Commons Collections
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Mert Guldur
> Attachments: patchFull.diff, patchSmall.diff, Test.java
>
>
> I am encountering a performance problem in
> CursorableLinkedList.containsAll() (which also affects
> NodeCachingLinkedList). It appears in version 3.2.1 and also in
> revision 1381642. I attached a test that exposes this problem and a
> patch that fixes it. On my machine, for this test, the patch provides
> a 182X speedup.
> To run the test, just do:
> $ java Test
> The output for the un-patched version is:
> Time is 5110
> The output for the patched version is:
> Time is 28
> The problem is that "containsAll(Collection coll)" iterates over
> the elements of "coll" and calls "contains" on "this", which is very
> slow, because "this" is a list.
> This problem is different from COLLECTIONS-416. As established in the
> COLLECTIONS-416 discussion, there the user was responsible for passing
> the proper data structure as the parameter "coll" to the method.
> However, for "AbstractLinkedList.containsAll()", the problem is not
> related to the collection passed as the parameter. The problem will
> always manifest for this method, irrespective of the parameter type.
> I attached two patches. Both implement a linear time algorithm using
> a HashSet. patchSmall.diff populates the HashSet eagerly, and
> patchFull.diff populates the HashSet lazily. patchFull.diff is faster
> than patchSmall.diff when containsAll() returns false after inspecting
> only a few elements, though in most cases they are equally fast. I am
> including patchSmall.diff just in case you prefer smaller code.
> There is a potential issue in using a HashSet for comparisons: HashSet
> uses "equals()" not "AbstractLinkedList.isEqualValue(Object value1,
> Object value2)". Currently, this is not a problem, because
> "AbstractLinkedList.isEqualValue" is implemented like this:
> {code:java|borderStyle=solid}
> protected boolean isEqualValue(Object value1, Object value2) {
> return (value1 == value2 || (value1 == null ? false :
> value1.equals(value2)));
> }
> {code}
> which is the code used by HashSet to check equality, and no subclass
> of AbstractLinkedList (there are only two subclasses:
> "CursorableLinkedList" and "NodeCachingLinkedList") overrides
> "isEqualValue".
> If "isEqualValue" is indeed likely to be overridden in the future, we
> can either (1) wrap the objects in the HashSet and define an
> "equals()" that calls "isEqualValue" or (2) detect if the method is
> really overridden through reflection with something like this:
> {code:java|borderStyle=solid}
> boolean isOverriden = false;
> Class curClass = this.getClass();
> while (!curClass.equals(AbstractLinkedList.class)) {
> try {
> curClass.getDeclaredMethod("isEqualValue", Object.class,
> Object.class);
> isOverriden = true;
> break;
> } catch (Exception e) {
> curClass = curClass.getSuperclass();
> }
> }
> {code}
--
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-429) Performance problem in MultiValueMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-429: Issue Type: Improvement (was: Bug) > Performance problem in MultiValueMap > > > Key: COLLECTIONS-429 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-429 > Project: Commons Collections > Issue Type: Improvement >Affects Versions: 3.2.1 > Environment: java 1.6.0_24 > Ubuntu 11.10 >Reporter: Adrian Nistor > Attachments: patchFull_AbstractHashedMap.diff, patchFull.diff, > patchFull_StaticBucketMap.diff, patchSmall_AbstractHashedMap.diff, > patchSmall.diff, patchSmall_StaticBucketMap.diff, > Test_AbstractHashedMap.java, TestDifferentParameter.java, Test.java, > Test_StaticBucketMap.java > > > Hi, > I am encountering a performance problem in MultiValueMap. It appears > in version 3.2.1 and also in revision 1366088. I attached a test that > exposes this problem and a patch that fixes it. On my machine, for > this test, the patch provides a 1158X speedup. > To run the test, just do: > $ java Test > The output for the un-patched version is: > Time is 44040 > The output for the patched version is: > Time is 38 > The attached test shows that, for a "MultiValueMap multi" object, the > following operation is very slow: > multi.values().containsAll(toContain); > "MultiValueMap.values()" returns a "MultiValueMap.Values" object, > which inherits containsAll() from "java.util.AbstractCollection", > which has quadratic complexity. > I attached two patches. Both patches override containsAll() and > implement a linear time algorithm. patchSmall.diff populates a > HashSet eagerly, and patchFull.diff populates a HashSet lazily. > patchFull.diff is faster than patchSmall.diff when containsAll() > returns false after inspecting only a few elements, though in most > cases they are equally fast. I am including patchSmall.diff just in > case you prefer smaller code. > Note that this problem is different from COLLECTIONS-416. As > established in the COLLECTIONS-416 discussion, there the user was > responsible for using the proper data structures as argument for the > method. > For "MultiValueMap.values()", the problem is not related to the > collection passed as parameter. The problem will always manifest for > this method, irrespective of the parameter type. I attached a test > (TestDifferentParameter.java) that shows that, even with a HashSet > parameter, the current problem still manifests (which did not happen > for COLLECTIONS-416). > This problem also exists for the two other "Values" classes > (AbstractHashedMap.Values, StaticBucketMap.Values). I attached tests > and patches for these classes as well. If you want me to file > separate reports, just let me know. > Is this truly a performance problem, or am I misunderstanding the > intended behavior? If so, can you please confirm that the patches are > correct? > Thanks, > Adrian -- 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-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573689#comment-13573689 ] Thomas Neidhart edited comment on COLLECTIONS-439 at 2/7/13 5:31 PM: - The TreeBag uses internally also a TreeMap, which requires that the used comparator must be consistent with equals, i.e. (compare(x,y) == 0) == x.equals\(y\). >From your description I understand that your comparator violates this >requirement, so this is not a bug, but could be an improvement. The attached bug has a few problems: * we can not add external dependencies to e.g. jena * missing test case was (Author: tn): The TreeBag uses internally also a TreeMap, which requires that the used comparator must be consistent with equals, i.e. (compare(x,y) == 0) == x.equals(y). >From your description I understand that your comparator violates this >requirement, so this is not a bug, but could be an improvement. The attached bug has a few problems: * we can not add external dependencies to e.g. jena * missing test case > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Bug > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Attachments: SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- 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-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-439: Issue Type: Improvement (was: Bug) > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Improvement > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Attachments: SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- 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-439) TreeBag with comparator does not store non-key duplicates.
[ https://issues.apache.org/jira/browse/COLLECTIONS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573689#comment-13573689 ] Thomas Neidhart commented on COLLECTIONS-439: - The TreeBag uses internally also a TreeMap, which requires that the used comparator must be consistent with equals, i.e. (compare(x,y) == 0) == x.equals(y). >From your description I understand that your comparator violates this >requirement, so this is not a bug, but could be an improvement. The attached bug has a few problems: * we can not add external dependencies to e.g. jena * missing test case > TreeBag with comparator does not store non-key duplicates. > -- > > Key: COLLECTIONS-439 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-439 > Project: Commons Collections > Issue Type: Bug > Components: Bag >Affects Versions: 3.2.1 >Reporter: Claude Warren > Attachments: SortedBag.java > > > When storing objects that are sorted by a Comparator, if the differences in > the objects are not in the comparator the same version of the object is > returned. I expected that the sorted bag would work like a DB table with a > non-unique key -- ordered but duplicate only determined by Object.equals(). > I have implemented this type of bag using a TreeMap of List. My > implementation uses the Jena ExtendedIterator to make building the iterator() > and array() methods easier. > Will attach the code. -- 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-441) MultiKeyMap.clone() should call super.clone()
[
https://issues.apache.org/jira/browse/COLLECTIONS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573680#comment-13573680
]
Thomas Neidhart commented on COLLECTIONS-441:
-
The change to AbstractHashedMap has been committed in r1443606.
> MultiKeyMap.clone() should call super.clone()
> -
>
> Key: COLLECTIONS-441
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-441
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: 4.0-beta-1
>Reporter: Thomas Vahrst
>Priority: Minor
>
> This issue addresses a findbugs issue:
> {quote}
> org.apache.commons.collections.map.MultiKeyMap.clone() does not call
> super.clone()
> {quote}
> The current clone() implementation creates a new MultiKeyMap instance. This
> will lead to problems when clone() is invoked on subclasses of MultiKeyMap.
> This is a corresponding junit test which fails:
> {code}
> class MultiKeyMapTest
> // Subclass to test clone() method
> private static class MultiKeyMapSubclass extends MultiKeyMap String>{
> }
> public void testCloneSubclass(){
> MultiKeyMapSubclass m = new MultiKeyMapSubclass();
>
> MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();
>
> }
> {code}
> Instead of creating a new MultiKeyMap instance, the clone() method should
> invoke super.clone() which leads in Object.clone(). This always returns an
> object of the correct type.
> {code}
> class MultiKeyMap{
> /**
> * Clones the map without cloning the keys or values.
> *
> * @return a shallow clone
> */
> @Override
> public MultiKeyMap clone() {
>try {
> MultiKeyMap m = (MultiKeyMap) super.clone();
> AbstractHashedMap, V> del =
> (AbstractHashedMap, V>)decorated().clone();
>
> m.map = del;
> ((AbstractMapDecorator)m).map = (Map) del;
> return m;
> } catch (CloneNotSupportedException ex) {
> throw new RuntimeException (ex); // this should never happen...
> }
> }
> {code}
> *Note*
> For serialisation compatibilty reasons to commons collections V.3.2,
> MultiKeyMap contains a map reference (the decorated map) which hides the same
> field in the super class AbstractMapDecorator. This is quite 'ugly' to
> understand and maintain.
> Should we consider to break the compatibility to the 3.2 version?
--
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] (COLLECTIONS-312) Minor changes to tidy modifiers for fields, methods and classes.
[ https://issues.apache.org/jira/browse/COLLECTIONS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-312. - Resolution: Fixed Fix Version/s: 4.0 Applied remaining changes from patch in r1443602. Did not touch the simplifications for equals methods as this may collide with findbugs / checkstyle, as well as some string concatenations. > Minor changes to tidy modifiers for fields, methods and classes. > > > Key: COLLECTIONS-312 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-312 > Project: Commons Collections > Issue Type: Improvement >Reporter: Peter Lawrey >Priority: Trivial > Fix For: 4.0 > > Attachments: commons-collections-static-analysis.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > These changes include > - private/package-local fields final if possible. > - private/package-local methods and classes static if possible > - remove fields which can be make local variables. > See the attached patch for the changes -- 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-454) SFTP: first access OK, second access: Unknown scheme "sftp" in URI "sftp://..."
[
https://issues.apache.org/jira/browse/VFS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573446#comment-13573446
]
MH edited comment on VFS-454 at 2/7/13 3:28 PM:
Forgot to note that this SFTP connection is established with a key:
-- code start ---
final SftpFileSystemConfigBuilder cb =
SftpFileSystemConfigBuilder.getInstance();
cb.setStrictHostKeyChecking(opts, "no"); //don't check, if host is in
$HOME/.ssh/known_hosts
if (fileKey != null) {
cb.setIdentities(opts, new File[]{fileKey}); //set private key
}//else: DO NOT ADD null VALUES IN Identities! (or you'll get " Could not
connect to SFTP server" errors!)
--- code end ---
I tried many close() calls without success:
--- code start ---
if (vfs != null) {
try {
LOGGER.info("--- clean up VFS --- 4");
if (dirRoot != null) {
dirRoot.close();
vfs.closeFileSystem(dirRoot.getFileSystem());
((StandardFileSystemManager)
vfs).closeFileSystem(dirRoot.getFileSystem());
}
((StandardFileSystemManager) vfs).close();
((DefaultFileSystemManager) vfs).close();
vfs.getFilesCache().close();
} catch (final Exception e) {
LOGGER.warning("Can't close SFTP root: "+e);
}
}
--- code end ---
was (Author: mhilpert):
Forgot to note that this SFTP connection is established with a key:
final SftpFileSystemConfigBuilder cb =
SftpFileSystemConfigBuilder.getInstance();
cb.setStrictHostKeyChecking(opts, "no"); //don't check, if host is in
$HOME/.ssh/known_hosts
if (fileKey != null) {
cb.setIdentities(opts, new File[]{fileKey}); //set private key
}//else: DO NOT ADD null VALUES IN Identities! (or you'll get " Could not
connect to SFTP server" errors!)
I tried many close() calls without success:
if (vfs != null) {
try {
LOGGER.info("--- clean up VFS --- 4");
if (dirRoot != null) {
dirRoot.close();
vfs.closeFileSystem(dirRoot.getFileSystem());
((StandardFileSystemManager)
vfs).closeFileSystem(dirRoot.getFileSystem());
}
((StandardFileSystemManager) vfs).close();
((DefaultFileSystemManager) vfs).close();
vfs.getFilesCache().close();
} catch (final Exception e) {
LOGGER.warning("Can't close SFTP root: "+e);
}
}
> SFTP: first access OK, second access: Unknown scheme "sftp" in URI
> "sftp://...";
> ---
>
> Key: VFS-454
> URL: https://issues.apache.org/jira/browse/VFS-454
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Java 1.7.0_13 64 Bit
>Reporter: MH
>Priority: Critical
>
> I access files from an SFTP server and accesm them roughly via
> -
> vfs.resolveFile(uri, opts);
> ...
> vfs.resolveFile(cwd, directory);
> ...
> cwd.getChildren();
> ...
> vfs.resolveFile(fn);
> ...
> ((DefaultFileSystemManager) vfs).close();
> --
> If the same code runs a second time, the first call to resolveFile() throws
> Unknown scheme "sftp" in URI "sftp://...";
> I tried
> vfs.closeFileSystem(children[0].getFileSystem());
> like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but
> this doesn't help!
--
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-454) SFTP: first access OK, second access: Unknown scheme "sftp" in URI "sftp://..."
[ https://issues.apache.org/jira/browse/VFS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] MH updated VFS-454: --- Summary: SFTP: first access OK, second access: Unknown scheme "sftp" in URI "sftp://..."; (was: SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://...";) > SFTP: first access OK, second access: Unknown scheme "sftp" in URI > "sftp://..."; > --- > > Key: VFS-454 > URL: https://issues.apache.org/jira/browse/VFS-454 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Java 1.7.0_13 64 Bit >Reporter: MH >Priority: Critical > > I access files from an SFTP server and accesm them roughly via > - > vfs.resolveFile(uri, opts); > ... > vfs.resolveFile(cwd, directory); > ... > cwd.getChildren(); > ... > vfs.resolveFile(fn); > ... > ((DefaultFileSystemManager) vfs).close(); > -- > If the same code runs a second time, the first call to resolveFile() throws > Unknown scheme "sftp" in URI "sftp://..."; > I tried > vfs.closeFileSystem(children[0].getFileSystem()); > like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but > this doesn't help! -- 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-454) SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://..."
[ https://issues.apache.org/jira/browse/VFS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573536#comment-13573536 ] MH edited comment on VFS-454 at 2/7/13 3:24 PM: Temporary workaround: remove (!!!) the closing call: --- code start --- //((DefaultFileSystemManager) vfs).close(); //THIS CAUSES FileSystemException: Unknown scheme "sftp" in URI "sftp://... --- code end --- Without this close() call, subsequent calls work ...! So much to (http://commons.apache.org/vfs/api.html): "You should make sure that you call close() on the manager when you are finished with it." ... was (Author: mhilpert): Temporary workaround: remove (!!!) the clsoing call: //((DefaultFileSystemManager) vfs).close(); //THIS CAUSES FileSystemException: Unknown scheme "sftp" in URI "sftp://... Without this close() call, subsequent calls work ...! So much to (http://commons.apache.org/vfs/api.html): "You should make sure that you call close() on the manager when you are finished with it." ... > SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI > "sftp://..."; > --- > > Key: VFS-454 > URL: https://issues.apache.org/jira/browse/VFS-454 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Java 1.7.0_13 64 Bit >Reporter: MH >Priority: Critical > > I access files from an SFTP server and accesm them roughly via > - > vfs.resolveFile(uri, opts); > ... > vfs.resolveFile(cwd, directory); > ... > cwd.getChildren(); > ... > vfs.resolveFile(fn); > ... > ((DefaultFileSystemManager) vfs).close(); > -- > If the same code runs a second time, the first call to resolveFile() throws > Unknown scheme "sftp" in URI "sftp://..."; > I tried > vfs.closeFileSystem(children[0].getFileSystem()); > like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but > this doesn't help! -- 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-455) No Version class available - hot to get version?
[ https://issues.apache.org/jira/browse/VFS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573580#comment-13573580 ] Gary Gregory commented on VFS-455: -- Get the version for any class from Class#getPackage() > No Version class available - hot to get version? > > > Key: VFS-455 > URL: https://issues.apache.org/jira/browse/VFS-455 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Java 1.7.0_13 64 Bit >Reporter: MH >Priority: Trivial > > Other Apache projects have a Version class (org.apache.xalan.Version, > org.apache.poi.Version, org.apache.fop.Version, org.apache.pdfbox.Version, > ...) to get version information. org.apache.commons.vfs2 should have an > equivalent Version class. -- 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=13573550#comment-13573550
]
Thomas Neidhart commented on COLLECTIONS-310:
-
Right now, when calling subList, a new, independent SetUniqueList is created
which is filled with elements from the backing list of the specified range.
The problem comes from the fact that this new SetUniqueList does not check for
uniqueness in the backing list, but only in the sublist. If we would create an
inner class (see for example ListOrderedMap), which would delegate the calls
(after properly adjusting some arguments, e.g. calculate real index) to the
backing SeUniqueList we could support the sublist contract.
The order is maintained and the uniqueness is validated by the backing list.
What do you think?
> 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
>
>
> 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/softwar
[jira] [Created] (VFS-455) No Version class available - hot to get version?
MH created VFS-455: -- Summary: No Version class available - hot to get version? Key: VFS-455 URL: https://issues.apache.org/jira/browse/VFS-455 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Java 1.7.0_13 64 Bit Reporter: MH Priority: Trivial Other Apache projects have a Version class (org.apache.xalan.Version, org.apache.poi.Version, org.apache.fop.Version, org.apache.pdfbox.Version, ...) to get version information. org.apache.commons.vfs2 should have an equivalent Version class. -- 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-454) SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://..."
[ https://issues.apache.org/jira/browse/VFS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573536#comment-13573536 ] MH commented on VFS-454: Temporary workaround: remove (!!!) the clsoing call: //((DefaultFileSystemManager) vfs).close(); //THIS CAUSES FileSystemException: Unknown scheme "sftp" in URI "sftp://... Without this close() call, subsequent calls work ...! So much to (http://commons.apache.org/vfs/api.html): "You should make sure that you call close() on the manager when you are finished with it." ... > SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI > "sftp://..."; > --- > > Key: VFS-454 > URL: https://issues.apache.org/jira/browse/VFS-454 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Java 1.7.0_13 64 Bit >Reporter: MH >Priority: Critical > > I access files from an SFTP server and accesm them roughly via > - > vfs.resolveFile(uri, opts); > ... > vfs.resolveFile(cwd, directory); > ... > cwd.getChildren(); > ... > vfs.resolveFile(fn); > ... > ((DefaultFileSystemManager) vfs).close(); > -- > If the same code runs a second time, the first call to resolveFile() throws > Unknown scheme "sftp" in URI "sftp://..."; > I tried > vfs.closeFileSystem(children[0].getFileSystem()); > like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but > this doesn't help! -- 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-454) SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://..."
[
https://issues.apache.org/jira/browse/VFS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573446#comment-13573446
]
MH edited comment on VFS-454 at 2/7/13 2:17 PM:
Forgot to note that this SFTP connection is established with a key:
final SftpFileSystemConfigBuilder cb =
SftpFileSystemConfigBuilder.getInstance();
cb.setStrictHostKeyChecking(opts, "no"); //don't check, if host is in
$HOME/.ssh/known_hosts
if (fileKey != null) {
cb.setIdentities(opts, new File[]{fileKey}); //set private key
}//else: DO NOT ADD null VALUES IN Identities! (or you'll get " Could not
connect to SFTP server" errors!)
I tried many close() calls without success:
if (vfs != null) {
try {
LOGGER.info("--- clean up VFS --- 4");
if (dirRoot != null) {
dirRoot.close();
vfs.closeFileSystem(dirRoot.getFileSystem());
((StandardFileSystemManager)
vfs).closeFileSystem(dirRoot.getFileSystem());
}
((StandardFileSystemManager) vfs).close();
((DefaultFileSystemManager) vfs).close();
vfs.getFilesCache().close();
} catch (final Exception e) {
LOGGER.warning("Can't close SFTP root: "+e);
}
}
was (Author: mhilpert):
Forgot to note that this SFTP connection is established with a key:
final SftpFileSystemConfigBuilder cb =
SftpFileSystemConfigBuilder.getInstance();
cb.setStrictHostKeyChecking(opts, "no"); //don't check, if host is in
$HOME/.ssh/known_hosts
if (fileKey != null) {
cb.setIdentities(opts, new File[]{fileKey}); //set private key
}//else: DO NOT ADD null VALUES IN Identities! (or you'll get " Could not
connect to SFTP server" errors!)
> SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI
> "sftp://...";
> ---
>
> Key: VFS-454
> URL: https://issues.apache.org/jira/browse/VFS-454
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Java 1.7.0_13 64 Bit
>Reporter: MH
>Priority: Critical
>
> I access files from an SFTP server and accesm them roughly via
> -
> vfs.resolveFile(uri, opts);
> ...
> vfs.resolveFile(cwd, directory);
> ...
> cwd.getChildren();
> ...
> vfs.resolveFile(fn);
> ...
> ((DefaultFileSystemManager) vfs).close();
> --
> If the same code runs a second time, the first call to resolveFile() throws
> Unknown scheme "sftp" in URI "sftp://...";
> I tried
> vfs.closeFileSystem(children[0].getFileSystem());
> like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but
> this doesn't help!
--
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-441) MultiKeyMap.clone() should call super.clone()
[
https://issues.apache.org/jira/browse/COLLECTIONS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573490#comment-13573490
]
Thomas Neidhart commented on COLLECTIONS-441:
-
Hi Thomas,
thanks for looking into this, just a few comments:
* I would prefer to throw an InternalError in clone() to be consistent (also
other maps do this now)
* removing the duplicate map makes sense, but I do not know yet if we should
do it, bc with 3.x is broken
in trunk (> 300 clirr errors), but supporting backwards compatible
serialization may be still wanted
this needs to be discussed on the mailinglist
> MultiKeyMap.clone() should call super.clone()
> -
>
> Key: COLLECTIONS-441
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-441
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
>Affects Versions: 4.0-beta-1
>Reporter: Thomas Vahrst
>Priority: Minor
>
> This issue addresses a findbugs issue:
> {quote}
> org.apache.commons.collections.map.MultiKeyMap.clone() does not call
> super.clone()
> {quote}
> The current clone() implementation creates a new MultiKeyMap instance. This
> will lead to problems when clone() is invoked on subclasses of MultiKeyMap.
> This is a corresponding junit test which fails:
> {code}
> class MultiKeyMapTest
> // Subclass to test clone() method
> private static class MultiKeyMapSubclass extends MultiKeyMap String>{
> }
> public void testCloneSubclass(){
> MultiKeyMapSubclass m = new MultiKeyMapSubclass();
>
> MultiKeyMapSubclass m2 = (MultiKeyMapSubclass) m.clone();
>
> }
> {code}
> Instead of creating a new MultiKeyMap instance, the clone() method should
> invoke super.clone() which leads in Object.clone(). This always returns an
> object of the correct type.
> {code}
> class MultiKeyMap{
> /**
> * Clones the map without cloning the keys or values.
> *
> * @return a shallow clone
> */
> @Override
> public MultiKeyMap clone() {
>try {
> MultiKeyMap m = (MultiKeyMap) super.clone();
> AbstractHashedMap, V> del =
> (AbstractHashedMap, V>)decorated().clone();
>
> m.map = del;
> ((AbstractMapDecorator)m).map = (Map) del;
> return m;
> } catch (CloneNotSupportedException ex) {
> throw new RuntimeException (ex); // this should never happen...
> }
> }
> {code}
> *Note*
> For serialisation compatibilty reasons to commons collections V.3.2,
> MultiKeyMap contains a map reference (the decorated map) which hides the same
> field in the super class AbstractMapDecorator. This is quite 'ugly' to
> understand and maintain.
> Should we consider to break the compatibility to the 3.2 version?
--
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-454) SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://..."
[
https://issues.apache.org/jira/browse/VFS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573446#comment-13573446
]
MH commented on VFS-454:
Forgot to note that this SFTP connection is established with a key:
final SftpFileSystemConfigBuilder cb =
SftpFileSystemConfigBuilder.getInstance();
cb.setStrictHostKeyChecking(opts, "no"); //don't check, if host is in
$HOME/.ssh/known_hosts
if (fileKey != null) {
cb.setIdentities(opts, new File[]{fileKey}); //set private key
}//else: DO NOT ADD null VALUES IN Identities! (or you'll get " Could not
connect to SFTP server" errors!)
> SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI
> "sftp://...";
> ---
>
> Key: VFS-454
> URL: https://issues.apache.org/jira/browse/VFS-454
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Java 1.7.0_13 64 Bit
>Reporter: MH
>Priority: Critical
>
> I access files from an SFTP server and accesm them roughly via
> -
> vfs.resolveFile(uri, opts);
> ...
> vfs.resolveFile(cwd, directory);
> ...
> cwd.getChildren();
> ...
> vfs.resolveFile(fn);
> ...
> ((DefaultFileSystemManager) vfs).close();
> --
> If the same code runs a second time, the first call to resolveFile() throws
> Unknown scheme "sftp" in URI "sftp://...";
> I tried
> vfs.closeFileSystem(children[0].getFileSystem());
> like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but
> this doesn't help!
--
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-454) SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://..."
MH created VFS-454: -- Summary: SFTP: first access OK, second acceds: Unknown scheme "sftp" in URI "sftp://..."; Key: VFS-454 URL: https://issues.apache.org/jira/browse/VFS-454 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Environment: Java 1.7.0_13 64 Bit Reporter: MH Priority: Critical I access files from an SFTP server and accesm them roughly via - vfs.resolveFile(uri, opts); ... vfs.resolveFile(cwd, directory); ... cwd.getChildren(); ... vfs.resolveFile(fn); ... ((DefaultFileSystemManager) vfs).close(); -- If the same code runs a second time, the first call to resolveFile() throws Unknown scheme "sftp" in URI "sftp://..."; I tried vfs.closeFileSystem(children[0].getFileSystem()); like stated in http://wiki.apache.org/commons/SimpleSftpFileDownload, but this doesn't help! -- 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] (MATH-933) Optimizers: Throw exception when bounds are passed to an algorithm that does not support them
[ https://issues.apache.org/jira/browse/MATH-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573436#comment-13573436 ] Gilles commented on MATH-933: - Other optimizers updated in revision 1443444. > Optimizers: Throw exception when bounds are passed to an algorithm that does > not support them > - > > Key: MATH-933 > URL: https://issues.apache.org/jira/browse/MATH-933 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Fix For: 3.2 > > > On the ML, it was suggested that it would better to throw an exception rather > than let an algorithm silently ignore the constraints passed to it. -- 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-369) Compilation error with newer versions of Jackrabbit
[
https://issues.apache.org/jira/browse/VFS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573360#comment-13573360
]
Jean-Marc Borer commented on VFS-369:
-
After searching on the internet how to get rid off standalone and start an
jackrabbit instance otherwise I found:
https://issues.apache.org/jira/browse/JCR-3284
Let's see if I can manage to modify the test case to get rid off
jackrabbit-standalone dependency.
> Compilation error with newer versions of Jackrabbit
> ---
>
> Key: VFS-369
> URL: https://issues.apache.org/jira/browse/VFS-369
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Cedric Nanni
> Attachments: pom.xml.patch, vfs-369-JR-2.5.3.diff, VFS-369.patch
>
>
> When I try to compile VFS on my computer I've got compilation errors due
> maybe because I use a more recent version of jackrabbit. I patched the code
> and now it compiles.
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> --- original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-10-24 20:35:41.0 +0200
> @@ -50,7 +50,7 @@ public final class ExceptionConverter
> {
> try
> {
> -Element error =
> davExc.toXml(DomUtil.BUILDER_FACTORY.newDocumentBuilder().newDocument());
> +Element error = davExc.toXml(DomUtil.createDocument());
> if (DomUtil.matches(error, DavException.XML_ERROR,
> DavConstants.NAMESPACE))
> {
> if (DomUtil.hasChildElement(error, "exception", null))
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> --- original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-10-24 20:35:41.0 +0200
> @@ -292,19 +292,17 @@ public class WebdavFileObject extends Ht
> URLFileName fileName = (URLFileName) getName();
> DavPropertySet properties = getProperties(fileName,
> PropFindMethod.PROPFIND_ALL_PROP,
> new DavPropertyNameSet(), false);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter = properties.iterator();
> +Iterator iter = properties.iterator();
> while (iter.hasNext())
> {
> -DavProperty property = iter.next();
> +DavProperty property = (DavProperty)iter.next();
> attributes.put(property.getName().toString(),
> property.getValue());
> }
> properties = getPropertyNames(fileName);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter2 = properties.iterator();
> +Iterator iter2 = properties.iterator();
> while (iter2.hasNext())
> {
> -DavProperty property = iter2.next();
> +DavProperty property = (DavProperty)iter2.next();
> if (!attributes.containsKey(property.getName().getName()))
> {
> property = getProperty(fileName, property.getName());
--
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-369) Compilation error with newer versions of Jackrabbit
[
https://issues.apache.org/jira/browse/VFS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573356#comment-13573356
]
Jean-Marc Borer commented on VFS-369:
-
Hmmm. I was too quick. In fact in still doesn't work because the
jackrabbit-standalone-1.6.5jar has uses an old call. The solution would be to
use jackrabbit-standalone-2.5.3.jar which exists
http://archive.apache.org/dist/jackrabbit/2.5.3/jackrabbit-standalone-2.5.3.jar
but is not published on official Maven repositories. What are they waiting for?
> Compilation error with newer versions of Jackrabbit
> ---
>
> Key: VFS-369
> URL: https://issues.apache.org/jira/browse/VFS-369
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Cedric Nanni
> Attachments: pom.xml.patch, vfs-369-JR-2.5.3.diff, VFS-369.patch
>
>
> When I try to compile VFS on my computer I've got compilation errors due
> maybe because I use a more recent version of jackrabbit. I patched the code
> and now it compiles.
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> --- original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-10-24 20:35:41.0 +0200
> @@ -50,7 +50,7 @@ public final class ExceptionConverter
> {
> try
> {
> -Element error =
> davExc.toXml(DomUtil.BUILDER_FACTORY.newDocumentBuilder().newDocument());
> +Element error = davExc.toXml(DomUtil.createDocument());
> if (DomUtil.matches(error, DavException.XML_ERROR,
> DavConstants.NAMESPACE))
> {
> if (DomUtil.hasChildElement(error, "exception", null))
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> --- original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-10-24 20:35:41.0 +0200
> @@ -292,19 +292,17 @@ public class WebdavFileObject extends Ht
> URLFileName fileName = (URLFileName) getName();
> DavPropertySet properties = getProperties(fileName,
> PropFindMethod.PROPFIND_ALL_PROP,
> new DavPropertyNameSet(), false);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter = properties.iterator();
> +Iterator iter = properties.iterator();
> while (iter.hasNext())
> {
> -DavProperty property = iter.next();
> +DavProperty property = (DavProperty)iter.next();
> attributes.put(property.getName().toString(),
> property.getValue());
> }
> properties = getPropertyNames(fileName);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter2 = properties.iterator();
> +Iterator iter2 = properties.iterator();
> while (iter2.hasNext())
> {
> -DavProperty property = iter2.next();
> +DavProperty property = (DavProperty)iter2.next();
> if (!attributes.containsKey(property.getName().getName()))
> {
> property = getProperty(fileName, property.getName());
--
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-369) Compilation error with newer versions of Jackrabbit
[
https://issues.apache.org/jira/browse/VFS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Borer updated VFS-369:
Attachment: pom.xml.patch
Patch for the root POM
> Compilation error with newer versions of Jackrabbit
> ---
>
> Key: VFS-369
> URL: https://issues.apache.org/jira/browse/VFS-369
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Cedric Nanni
> Attachments: pom.xml.patch, vfs-369-JR-2.5.3.diff, VFS-369.patch
>
>
> When I try to compile VFS on my computer I've got compilation errors due
> maybe because I use a more recent version of jackrabbit. I patched the code
> and now it compiles.
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> --- original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-10-24 20:35:41.0 +0200
> @@ -50,7 +50,7 @@ public final class ExceptionConverter
> {
> try
> {
> -Element error =
> davExc.toXml(DomUtil.BUILDER_FACTORY.newDocumentBuilder().newDocument());
> +Element error = davExc.toXml(DomUtil.createDocument());
> if (DomUtil.matches(error, DavException.XML_ERROR,
> DavConstants.NAMESPACE))
> {
> if (DomUtil.hasChildElement(error, "exception", null))
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> --- original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-10-24 20:35:41.0 +0200
> @@ -292,19 +292,17 @@ public class WebdavFileObject extends Ht
> URLFileName fileName = (URLFileName) getName();
> DavPropertySet properties = getProperties(fileName,
> PropFindMethod.PROPFIND_ALL_PROP,
> new DavPropertyNameSet(), false);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter = properties.iterator();
> +Iterator iter = properties.iterator();
> while (iter.hasNext())
> {
> -DavProperty property = iter.next();
> +DavProperty property = (DavProperty)iter.next();
> attributes.put(property.getName().toString(),
> property.getValue());
> }
> properties = getPropertyNames(fileName);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter2 = properties.iterator();
> +Iterator iter2 = properties.iterator();
> while (iter2.hasNext())
> {
> -DavProperty property = iter2.next();
> +DavProperty property = (DavProperty)iter2.next();
> if (!attributes.containsKey(property.getName().getName()))
> {
> property = getProperty(fileName, property.getName());
--
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-369) Compilation error with newer versions of Jackrabbit
[
https://issues.apache.org/jira/browse/VFS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573294#comment-13573294
]
Jean-Marc Borer commented on VFS-369:
-
I found a solution. However the test continues to fail, but this time not
because of a compilation error.
You have to modify the root POM: exclude the default dependencies of
jackrabbit-standalone and provide your own ones with the proper version. Root
POM Patch included
> Compilation error with newer versions of Jackrabbit
> ---
>
> Key: VFS-369
> URL: https://issues.apache.org/jira/browse/VFS-369
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Cedric Nanni
> Attachments: vfs-369-JR-2.5.3.diff, VFS-369.patch
>
>
> When I try to compile VFS on my computer I've got compilation errors due
> maybe because I use a more recent version of jackrabbit. I patched the code
> and now it compiles.
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> --- original//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/ExceptionConverter.java
> 2011-10-24 20:35:41.0 +0200
> @@ -50,7 +50,7 @@ public final class ExceptionConverter
> {
> try
> {
> -Element error =
> davExc.toXml(DomUtil.BUILDER_FACTORY.newDocumentBuilder().newDocument());
> +Element error = davExc.toXml(DomUtil.createDocument());
> if (DomUtil.matches(error, DavException.XML_ERROR,
> DavConstants.NAMESPACE))
> {
> if (DomUtil.hasChildElement(error, "exception", null))
> diff -rupN
> original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> --- original//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-08-18 06:57:10.0 +0200
> +++ patched//org/apache/commons/vfs2/provider/webdav/WebdavFileObject.java
> 2011-10-24 20:35:41.0 +0200
> @@ -292,19 +292,17 @@ public class WebdavFileObject extends Ht
> URLFileName fileName = (URLFileName) getName();
> DavPropertySet properties = getProperties(fileName,
> PropFindMethod.PROPFIND_ALL_PROP,
> new DavPropertyNameSet(), false);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter = properties.iterator();
> +Iterator iter = properties.iterator();
> while (iter.hasNext())
> {
> -DavProperty property = iter.next();
> +DavProperty property = (DavProperty)iter.next();
> attributes.put(property.getName().toString(),
> property.getValue());
> }
> properties = getPropertyNames(fileName);
> -@SuppressWarnings("unchecked") // iterator() is documented to
> return DavProperty instances
> -Iterator iter2 = properties.iterator();
> +Iterator iter2 = properties.iterator();
> while (iter2.hasNext())
> {
> -DavProperty property = iter2.next();
> +DavProperty property = (DavProperty)iter2.next();
> if (!attributes.containsKey(property.getName().getName()))
> {
> property = getProperty(fileName, property.getName());
--
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] (JCS-104) LRUMemoryCache does not perform well in multi threads enviroment
Leon Ma created JCS-104: --- Summary: LRUMemoryCache does not perform well in multi threads enviroment Key: JCS-104 URL: https://issues.apache.org/jira/browse/JCS-104 Project: Commons JCS Issue Type: Improvement Components: Composite Cache Affects Versions: jcs-1.3 Reporter: Leon Ma Hi, Thomas I'm using JCS 1.3 and found the LRUMemoryCache.get() is synchronized. Also, the underlying map is HashTable. I have some lock contention when using multiple threads to hit cache. Do you have any plan to improve it? (maybe in 2.0.0 release?) Thanks Ma Leon -- 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
