[jira] Updated: (VFS-304) Using VFS with Alfresco FTP does not work.
[ https://issues.apache.org/jira/browse/VFS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom updated VFS-304: Attachment: FTPClientWrapper.java The improved wrapper. Tests run: 974, Failures: 0, Errors: 0, Skipped: 0 Using VFS with Alfresco FTP does not work. -- Key: VFS-304 URL: https://issues.apache.org/jira/browse/VFS-304 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Alfresco 3.2r Reporter: Tom Attachments: FTPClientWrapper.java It seems Alfresco's FTP implementation does not allow for compound paths but only works from the current directory. This requires some methods in FtpClientWrapper to be modified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VFS-304) Using VFS with Alfresco FTP does not work.
[ https://issues.apache.org/jira/browse/VFS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom updated VFS-304: Attachment: (was: FTPClientWrapper.java) Using VFS with Alfresco FTP does not work. -- Key: VFS-304 URL: https://issues.apache.org/jira/browse/VFS-304 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Alfresco 3.2r Reporter: Tom Attachments: FTPClientWrapper.java It seems Alfresco's FTP implementation does not allow for compound paths but only works from the current directory. This requires some methods in FtpClientWrapper to be modified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-353) Constrained version of the Nelder-Mead simplex method and bi-cubic interpolation
Constrained version of the Nelder-Mead simplex method and bi-cubic interpolation Key: MATH-353 URL: https://issues.apache.org/jira/browse/MATH-353 Project: Commons Math Issue Type: Wish Reporter: Dimitri Pourbaix Priority: Minor The library http://www.ee.ucl.ac.uk/~mflanaga/java/ offers a constrained version of the Nelder-Mead simplex method through the addition of a penalty function. Such a possibility seems to be missing from commons-math. The same library also offers some bi-cubic interpolation which is also absent in commons-math. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-609) Support lazy initialization using atomic variables
[
https://issues.apache.org/jira/browse/LANG-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-609:
---
Fix Version/s: 3.0
Support lazy initialization using atomic variables
--
Key: LANG-609
URL: https://issues.apache.org/jira/browse/LANG-609
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Oliver Heger
Priority: Minor
Fix For: 3.0
In the new concurrent package there is already the {{LazyInitializer}} class
implementing the double-check idiom for lazy initialization of instance
fields. Another way to perform initialization lazily would be the usage of
atomic variables. This solution would not need synchronization at all. If
there is low contention (not many threads in parallel), it is more efficient
than synchronized access. Its drawback is that the initialization may be done
multiple times if multiple threads access the initializer almost at the same
time (however, it can be guaranteed that always the same object created by
the initializer is returned).
This is a proposal to add an {{AtomicInitializer}} class as an alternative to
{{LazyInitializer}} that operates on {{AtomicReference}} variables.
In order to make the initializers smoothly exchangable, it would make sense
for them to share a common interface. This interface could also be
implemented by the {{BackgroundInitializer}} class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-609) Support lazy initialization using atomic variables
[
https://issues.apache.org/jira/browse/LANG-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846469#action_12846469
]
Henri Yandell commented on LANG-609:
Sounds good.
Support lazy initialization using atomic variables
--
Key: LANG-609
URL: https://issues.apache.org/jira/browse/LANG-609
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Oliver Heger
Priority: Minor
Fix For: 3.0
In the new concurrent package there is already the {{LazyInitializer}} class
implementing the double-check idiom for lazy initialization of instance
fields. Another way to perform initialization lazily would be the usage of
atomic variables. This solution would not need synchronization at all. If
there is low contention (not many threads in parallel), it is more efficient
than synchronized access. Its drawback is that the initialization may be done
multiple times if multiple threads access the initializer almost at the same
time (however, it can be guaranteed that always the same object created by
the initializer is returned).
This is a proposal to add an {{AtomicInitializer}} class as an alternative to
{{LazyInitializer}} that operates on {{AtomicReference}} variables.
In order to make the initializers smoothly exchangable, it would make sense
for them to share a common interface. This interface could also be
implemented by the {{BackgroundInitializer}} class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-604) Optimize isBlank() for untrimmed strings
[
https://issues.apache.org/jira/browse/LANG-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846475#action_12846475
]
Henri Yandell commented on LANG-604:
I'm not sure I buy that most of the strings checked are untrimmed.
I'd expect most to be either a) blank or b) normal user input. If the first
character is whitespace; then I could believe that it's untrimmed.
So:
+public static boolean isBlank(CharSequence cs) {
+int strLen;
+if (cs == null || (strLen = cs.length()) == 0) {
+return true;
+}
+// Optimized - check first character
+if (!Character.isWhitespace(cs.charAt(0))) {
+return false;
+}
+// Optimized - starts in the middle and works out with the assumption
that
+// most input starting with whitespace are untrimmed strings
+for (int m = 1 + strLen / 2, i = 1; m strLen; m++, i++) {
+if (!Character.isWhitespace(cs.charAt(m)) ||
!Character.isWhitespace(cs.charAt(i))) {
+return false;
+}
+}
+return true;
+}
Any thoughts?
Optimize isBlank() for untrimmed strings
Key: LANG-604
URL: https://issues.apache.org/jira/browse/LANG-604
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.0
Reporter: Kai Gülzau
Priority: Minor
Change isBlank() to start iteration in the middle of the String.
So you get better performance for untrimmed Strings likedummy .
Here is my proposal:
public static boolean isBlank(CharSequence cs) {
int strLen;
if (cs == null || (strLen = cs.length()) == 0) {
return true;
}
int mid = strLen / 2, i = mid;
for (; i strLen; i++) {
if (!Character.isWhitespace(cs.charAt(i))) {
return false;
}
}
for (i = 0; i mid; i++) {
if (!Character.isWhitespace(cs.charAt(i))) {
return false;
}
}
return true;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-600) Javadoc is incorrect for public static int lastIndexOf(String str, String searchStr)
[ https://issues.apache.org/jira/browse/LANG-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-600. -- Resolution: Fixed svn ci -m Fixing javadoc per LANG-600. Examples already in tests. src/main/java/org/apache/commons/lang3/StringUtils.java Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java Transmitting file data . Committed revision 924372. Javadoc is incorrect for public static int lastIndexOf(String str, String searchStr) Key: LANG-600 URL: https://issues.apache.org/jira/browse/LANG-600 Project: Commons Lang Issue Type: Task Components: lang.* Affects Versions: 2.4 Reporter: Sean Montgomery Priority: Trivial Fix For: 3.0 The javadoc's examples show how indexOf should work not lastIndexOf. StringUtils.lastIndexOf(null, *) = -1 StringUtils.lastIndexOf(*, null) = -1 StringUtils.lastIndexOf(, ) = 0 StringUtils.lastIndexOf(aabaabaa, a) = 0 StringUtils.lastIndexOf(aabaabaa, b) = 2 StringUtils.lastIndexOf(aabaabaa, ab) = 1 StringUtils.lastIndexOf(aabaabaa, ) = 8 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-606) EqualsBuilder causes StackOverflowException
[
https://issues.apache.org/jira/browse/LANG-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846514#action_12846514
]
Henri Yandell commented on LANG-606:
Can you check the patch? It doesn't apply cleanly, but neither file in question
has changed since you posted the patch.
EqualsBuilder causes StackOverflowException
---
Key: LANG-606
URL: https://issues.apache.org/jira/browse/LANG-606
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 2.5
Reporter: Oliver Sauder
Priority: Minor
Fix For: 3.0
Attachments: EqualsBuilderCyclicalObjectReferences.patch
EqualsBuilder causes StackOverflowException when comparing objects with
cyclical object references.
e,g.
static class TestObjectReference {
@SuppressWarnings(unused)
private TestObjectReference reference;
@SuppressWarnings(unused)
private TestObject one;
public TestObjectReference(int one) {
this.one = new TestObject(one);
}
public void setObjectReference(
TestObjectReference reference) {
this.reference = reference;
}
@Override
public boolean equals(Object obj) {
return EqualsBuilder.reflectionEquals(this, obj);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-597) Add more utility methods for generic types
[ https://issues.apache.org/jira/browse/LANG-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846519#action_12846519 ] Henri Yandell commented on LANG-597: Can we have the patch without the Copyright statement at the top? It gets confusing to mix all the various copyright statements in the source; instead Apache has an audit trail via SVN, JIRA and signed documents to define the copyright mix on a project. Minor note to avoid the static import as it makes the code less readable (though Matt and I enjoy arguing on this one :) ). Also not liking all the imports to avoid fully describing in the javadoc. I've not dug far into the code itself. Hoping Matt does :) Add more utility methods for generic types -- Key: LANG-597 URL: https://issues.apache.org/jira/browse/LANG-597 Project: Commons Lang Issue Type: Improvement Components: lang.reflect.* Environment: Java 1.5+ Reporter: David M. Sledge Priority: Minor Fix For: 3.0 Attachments: TypeUtils-Added-Utitlities-Lang-597-2010-03-03.patch Added type utilities include: * checking if one type can be assigned to another type * determining if a value can be assigned to a given generic type * for a class that declares type variables, determining what the type arguments would be based on a generic sub or super type * determining if a group of types satisfy the bounds of a group of type variables -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-162) When waiting threads are interrupted, pool can leak capacity
[ https://issues.apache.org/jira/browse/POOL-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846575#action_12846575 ] Mark Thomas commented on POOL-162: -- This should be fixed but I'd appreciate another pair of eyes on this before marking it as resolved. When waiting threads are interrupted, pool can leak capacity Key: POOL-162 URL: https://issues.apache.org/jira/browse/POOL-162 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4 Reporter: Phil Steitz As reported on commons-dev (http://markmail.org/message/aqb23nnzyy2ar3vs), when waiting threads are interrupted, GOP, GKOP may leak capacity. I do not yet have a test case to confirm this, but I suspect that the problem reported by the user is caused by a missing _allocationQueue.remove(latch) before rethrowing InterruptedException in borrowObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CONFIGURATION-411) XMLConfiguration: node text: first \ (backslash) of \\ (double backslash) character will not be in the configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger closed CONFIGURATION-411.
--
XMLConfiguration: node text: first \ (backslash) of \\ (double backslash)
character will not be in the configuration
Key: CONFIGURATION-411
URL: https://issues.apache.org/jira/browse/CONFIGURATION-411
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Reporter: Jochen Hebbrecht
Priority: Minor
Attachments: xmldoublebackslash.rar
I have this configuration element in my XML configuration:
{code}
working-folder\\test\test/working-folder
{code}
... but when I want to print out the value, I notice the content of this node
changed to:
{code} \test\test{code}
So the first \ has disappeared
I've created a M2 project that simulates the problem. Just hit mvn
eclipse:eclipse and run the Test.java file :-).
The problem is situated in:
*org.apache.commons.configuration.PropertyConverter.class*. Check the method:
{code} public static List split(String s, char delimiter, boolean trim){code}
= line 505.
begin = 0
c = \
inEscape = true
begin = 1
c= \
if (c \!= delimiter c == LIST_ESC_CHAR) = only the second char will be
printed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONFIGURATION-411) XMLConfiguration: node text: first \ (backslash) of \\ (double backslash) character will not be in the configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-411.
Resolution: Invalid
The reporter agreed that this is not a bug.
XMLConfiguration: node text: first \ (backslash) of \\ (double backslash)
character will not be in the configuration
Key: CONFIGURATION-411
URL: https://issues.apache.org/jira/browse/CONFIGURATION-411
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Reporter: Jochen Hebbrecht
Priority: Minor
Attachments: xmldoublebackslash.rar
I have this configuration element in my XML configuration:
{code}
working-folder\\test\test/working-folder
{code}
... but when I want to print out the value, I notice the content of this node
changed to:
{code} \test\test{code}
So the first \ has disappeared
I've created a M2 project that simulates the problem. Just hit mvn
eclipse:eclipse and run the Test.java file :-).
The problem is situated in:
*org.apache.commons.configuration.PropertyConverter.class*. Check the method:
{code} public static List split(String s, char delimiter, boolean trim){code}
= line 505.
begin = 0
c = \
inEscape = true
begin = 1
c= \
if (c \!= delimiter c == LIST_ESC_CHAR) = only the second char will be
printed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-412) Cannot use DatabaseConfiguration if the datasource has autocommit = false
Cannot use DatabaseConfiguration if the datasource has autocommit = false - Key: CONFIGURATION-412 URL: https://issues.apache.org/jira/browse/CONFIGURATION-412 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Windows / Linux - Database Oracle 11 Reporter: Stefano Bertini Priority: Critical If using a DatabaseConfiguration object with a datasource that has *autocommit = false*, the setProperty method fails with a *duplicate key* error. This happens because in the setProperty method the two calls _clearProperty(key)_ and _addProperty(key, value)_ can retrieve two different connections from the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAEMON-144) Do the samples really need to use Collections ExtendedProperties ?
Do the samples really need to use Collections ExtendedProperties ? -- Key: DAEMON-144 URL: https://issues.apache.org/jira/browse/DAEMON-144 Project: Commons Daemon Issue Type: Improvement Reporter: Sebb Do the samples really need to use Collections ExtendedProperties ? It would simply building and deploying the samples if they did not need the extra library. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-162) When waiting threads are interrupted, pool can leak capacity
[ https://issues.apache.org/jira/browse/POOL-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846729#action_12846729 ] Phil Steitz commented on POOL-162: -- Thanks, Mark! Gave me a headache, but the test and fix look good, modulo one comment. With your patch, if the latch has been served when the thread is interrupted, we do not propagate the interrupt, but let the thread continue and get served. This seems reasonable for most use cases. The alternative would be to handle mayCreate and pair != null separately, in the second case destroying the object and in both cases removing the latch from the queue and setting thread interrupt status. If the interrupt is to shorten or end the wait, the patch impl is probably best. If for another reason, the client might rather propagate the exception and not use pool capacity. I can't t think of realistic use cases where the second would be the case, so unless someone else can, I am +1 on resolving this based on the fix in r924479 When waiting threads are interrupted, pool can leak capacity Key: POOL-162 URL: https://issues.apache.org/jira/browse/POOL-162 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4 Reporter: Phil Steitz As reported on commons-dev (http://markmail.org/message/aqb23nnzyy2ar3vs), when waiting threads are interrupted, GOP, GKOP may leak capacity. I do not yet have a test case to confirm this, but I suspect that the problem reported by the user is caused by a missing _allocationQueue.remove(latch) before rethrowing InterruptedException in borrowObject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
