[jira] [Resolved] (PROXY-21) Remove Cyclic Package Dependencies
[ https://issues.apache.org/jira/browse/PROXY-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved PROXY-21. --- Resolution: Fixed > Remove Cyclic Package Dependencies > -- > > Key: PROXY-21 > URL: https://issues.apache.org/jira/browse/PROXY-21 > Project: Commons Proxy > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: James Carman >Assignee: James Carman > Fix For: 2.0 > > > The ProxyUtils class uses the NullInvoker class to create "null objects" and > the NullInvoker class calls back to ProxyUtils to determine the proper "null" > response to a method. This cycle needs to be broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROXY-21) Remove Cyclic Package Dependencies
James Carman created PROXY-21: - Summary: Remove Cyclic Package Dependencies Key: PROXY-21 URL: https://issues.apache.org/jira/browse/PROXY-21 Project: Commons Proxy Issue Type: Improvement Affects Versions: 2.0 Reporter: James Carman Assignee: James Carman Fix For: 2.0 The ProxyUtils class uses the NullInvoker class to create "null objects" and the NullInvoker class calls back to ProxyUtils to determine the proper "null" response to a method. This cycle needs to be broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROXY-20) Implement A SwitchInterceptor
[ https://issues.apache.org/jira/browse/PROXY-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved PROXY-20. --- Resolution: Fixed > Implement A SwitchInterceptor > - > > Key: PROXY-20 > URL: https://issues.apache.org/jira/browse/PROXY-20 > Project: Commons Proxy > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: James Carman >Assignee: James Carman >Priority: Minor > Fix For: 2.0 > > > An interceptor which supports registering multiple "cases" to be checked for > each invocation. A "case" consists of an InvocationMatcher, which returns > true/false given an Invocation object, and its corresponding Interceptor > which is to be called if the case matches the Invocation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROXY-20) Implement A SwitchInterceptor
James Carman created PROXY-20: - Summary: Implement A SwitchInterceptor Key: PROXY-20 URL: https://issues.apache.org/jira/browse/PROXY-20 Project: Commons Proxy Issue Type: New Feature Affects Versions: 2.0 Reporter: James Carman Assignee: James Carman Priority: Minor Fix For: 2.0 An interceptor which supports registering multiple "cases" to be checked for each invocation. A "case" consists of an InvocationMatcher, which returns true/false given an Invocation object, and its corresponding Interceptor which is to be called if the case matches the Invocation. -- 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] (PROXY-18) Invocation should return the proxy object, rather than the target, from #getProxy()
[
https://issues.apache.org/jira/browse/PROXY-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459511#comment-13459511
]
James Carman commented on PROXY-18:
---
It has been so long since I've been in this code. I can't recall why I
structured the unit tests to specifically look for this behavior. If it
doesn't make sense, let's change it. Good catch!
> Invocation should return the proxy object, rather than the target, from
> #getProxy()
> ---
>
> Key: PROXY-18
> URL: https://issues.apache.org/jira/browse/PROXY-18
> Project: Commons Proxy
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Matt Benson
> Attachments: PROXY-18.patch.txt
>
>
> 1. It's nobody's business but the proxy's creator what the target object is.
> 2. Unless the proxy instance is available, e.g. fluent interfaces cannot be
> properly proxied.
> It's possible that _both_ the {{target}} and {{proxy}} objects could be
> provided by the {{Invocation}} but as already stated I find that neither
> necessary nor desirable. I'll be attaching a patch for community review.
--
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] (DBCP-392) Remove Occurrences of Multiple Statements on One Line
James Carman created DBCP-392: - Summary: Remove Occurrences of Multiple Statements on One Line Key: DBCP-392 URL: https://issues.apache.org/jira/browse/DBCP-392 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4 Reporter: James Carman Priority: Minor The DelegatingConnection class has many methods that are one-liners, but it's actually multiple statements. When debugging, it can make it appear as if the code is being executed twice (it did to me) at first glance. If it's multiple statements, we should use multiple lines of 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] (DBCP-386) Osgi imports and classpath for Class.forName
[ https://issues.apache.org/jira/browse/DBCP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated DBCP-386: -- Fix Version/s: 1.4.1 > Osgi imports and classpath for Class.forName > > > Key: DBCP-386 > URL: https://issues.apache.org/jira/browse/DBCP-386 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4 > Environment: OSGi, felix, equinox, karaf >Reporter: Edstrom Johan >Priority: Minor > Fix For: 1.4.1 > > > The bundle MANIFEST does not provide a Dynamic import, this forces you to > either attach data sources as a fragment or load them via exposed system > classes. > A dynamic import * would simplify this. > * -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-386) Osgi imports and classpath for Class.forName
[ https://issues.apache.org/jira/browse/DBCP-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395984#comment-13395984 ] James Carman commented on DBCP-386: --- Thank you, Johan! We'll get this added in right away. > Osgi imports and classpath for Class.forName > > > Key: DBCP-386 > URL: https://issues.apache.org/jira/browse/DBCP-386 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4 > Environment: OSGi, felix, equinox, karaf >Reporter: Edstrom Johan >Priority: Minor > Fix For: 1.4.1 > > > The bundle MANIFEST does not provide a Dynamic import, this forces you to > either attach data sources as a fragment or load them via exposed system > classes. > A dynamic import * would simplify this. > * -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-255) XML handler to serialize/de-serialize FlieEntrys to/from XML
[ https://issues.apache.org/jira/browse/IO-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926736#action_12926736 ] James Carman commented on IO-255: - Does java.beans.XMLEncoder/XMLDecoder work out of the box with this particular class? > XML handler to serialize/de-serialize FlieEntrys to/from XML > > > Key: IO-255 > URL: https://issues.apache.org/jira/browse/IO-255 > Project: Commons IO > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Attachments: FileEntryXmlHandler.java > > > It may be usefule to *capture* the state of a Filesystem and serialize it. > I've been playing with a handler that can serialize/de-serialize a FileEntry > and its children to/from XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (POOL-174) Configuration classes must be thread-safe
[ https://issues.apache.org/jira/browse/POOL-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924580#action_12924580 ] James Carman commented on POOL-174: --- Why not make the config object immutable, but make the config property on the configured object mutable? > Configuration classes must be thread-safe > - > > Key: POOL-174 > URL: https://issues.apache.org/jira/browse/POOL-174 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 2.0 > > > New Configuration classes added with POOL-173 have to be made thread-safety -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (POOL-174) Configuration classes must be thread-safe
[ https://issues.apache.org/jira/browse/POOL-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated POOL-174: -- Summary: Configuration classes must be thread-safe (was: Configuration classes must be thread-safety) > Configuration classes must be thread-safe > - > > Key: POOL-174 > URL: https://issues.apache.org/jira/browse/POOL-174 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 2.0 > > > New Configuration classes added with POOL-173 have to be made thread-safety -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MATH-429) KMeansPlusPlusClusterer breaks by division by zero
[ https://issues.apache.org/jira/browse/MATH-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924063#action_12924063 ] James Carman edited comment on MATH-429 at 10/23/10 9:22 AM: - How about make it configurable? Take a look at how the Mallet project did it: http://mallet.cs.umass.edu/api/cc/mallet/cluster/KMeans.html By the way, I have suggested that they try to enter the Incubator here at the ASF and they seem somewhat receptive to the idea! was (Author: jwcarman): How about make it configurable? > KMeansPlusPlusClusterer breaks by division by zero > -- > > Key: MATH-429 > URL: https://issues.apache.org/jira/browse/MATH-429 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.1 > Environment: Java, Windows >Reporter: Erik van Ingen >Priority: Blocker > Attachments: KMeansPlusPlusClustererTest.java > > Original Estimate: 3h > Remaining Estimate: 3h > > For a certain space, KMeansPlusPlusClusterer breaks. This is a blocker > because this space occurs in our domain. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-429) KMeansPlusPlusClusterer breaks by division by zero
[ https://issues.apache.org/jira/browse/MATH-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924063#action_12924063 ] James Carman commented on MATH-429: --- How about make it configurable? > KMeansPlusPlusClusterer breaks by division by zero > -- > > Key: MATH-429 > URL: https://issues.apache.org/jira/browse/MATH-429 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.1 > Environment: Java, Windows >Reporter: Erik van Ingen >Priority: Blocker > Attachments: KMeansPlusPlusClustererTest.java > > Original Estimate: 3h > Remaining Estimate: 3h > > For a certain space, KMeansPlusPlusClusterer breaks. This is a blocker > because this space occurs in our domain. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-315) NullPointerExceptions in WebdavFileObject when fetching properties
[ https://issues.apache.org/jira/browse/VFS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907426#action_12907426 ] James Carman commented on VFS-315: -- Please provide a test case that exhibits the issue. > NullPointerExceptions in WebdavFileObject when fetching properties > -- > > Key: VFS-315 > URL: https://issues.apache.org/jira/browse/VFS-315 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: windows with IIS as webdav host. >Reporter: David Hausladen >Priority: Critical > Fix For: 2.0 > > Attachments: NPE.patch > > > The WebdavFileObject sometimes throws a NullPointerException in > doGetAttributes in the body of the second loop. For some reason, when it > goes out to resolve the property, it sometimes is returned as a null > DavProperty. When the DavProperty's getName method is called, there's a NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-316) HttpFileSystemConfigBuilder needs option for preemptive authentication
[ https://issues.apache.org/jira/browse/VFS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907425#action_12907425 ] James Carman commented on VFS-316: -- Do you have a test case for this? > HttpFileSystemConfigBuilder needs option for preemptive authentication > -- > > Key: VFS-316 > URL: https://issues.apache.org/jira/browse/VFS-316 > Project: Commons VFS > Issue Type: Bug > Environment: IIS WebDAV >Reporter: David Hausladen > Fix For: 2.0 > > Attachments: PREEMPTIVEAUTH.patch > > > I find that the credential challenges produced by the WebdavFileSystem as it > uses the HttpClient creates a great deal of superfluous HTTP traffic just to > perform BASIC authentication. In some scenarios, dumbed-down preemptive > authentication is needed for swifter traversals of the repository. > I suggest adding preemptive authentication to HttpFileSystemConfigBuilder and > HttpClientFactory to address this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-264) FTPS support for VFS
[ https://issues.apache.org/jira/browse/VFS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved VFS-264. -- Resolution: Fixed Patch applied. > FTPS support for VFS > > > Key: VFS-264 > URL: https://issues.apache.org/jira/browse/VFS-264 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 > Environment: All >Reporter: Scott Bjerstedt >Priority: Minor > Fix For: 2.0 > > Attachments: FTPS-support.patch > > > The current version of VFS doesn't support FTPS as a provider -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-649) BooleanUtils.toBooleanObject to support single character input
[ https://issues.apache.org/jira/browse/LANG-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905203#action_12905203 ] James Carman commented on LANG-649: --- That's what I mean. Is this going to get more complicated in the long run? > BooleanUtils.toBooleanObject to support single character input > -- > > Key: LANG-649 > URL: https://issues.apache.org/jira/browse/LANG-649 > Project: Commons Lang > Issue Type: Improvement >Reporter: Henri Yandell > Fix For: 3.0 > > > BooleanUtils.toBooleanObject could be supporting t/f and y/n. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-649) BooleanUtils.toBooleanObject to support single character input
[ https://issues.apache.org/jira/browse/LANG-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905183#action_12905183 ] James Carman commented on LANG-649: --- If we do that (which I don't think is a horrible idea), are folks going to ask for different language support? I can see that becoming a maintenance nightmare. > BooleanUtils.toBooleanObject to support single character input > -- > > Key: LANG-649 > URL: https://issues.apache.org/jira/browse/LANG-649 > Project: Commons Lang > Issue Type: Improvement >Reporter: Henri Yandell > Fix For: 3.0 > > > BooleanUtils.toBooleanObject could be supporting t/f and y/n. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-285) Wish : method unaccent
[ https://issues.apache.org/jira/browse/LANG-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904146#action_12904146 ] James Carman edited comment on LANG-285 at 8/30/10 9:12 AM: This seems like an awful lot of code for something that's 1 or 2 lines of code if java.text.Normalizer is available from JDK6. was (Author: jwcarman): Is this code going to change when Oracle decides to change the name of the class to come.oracle.*? They've already messed up quite a few folks by changing the JVM name on their latest release from what I understand. Also, is it smart to depend on non-core classes here? What about other JVMs? Will this code not work on other JVMs? > Wish : method unaccent > -- > > Key: LANG-285 > URL: https://issues.apache.org/jira/browse/LANG-285 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Guillaume Coté >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-285-unaccent-using-Collator.patch, LANG-285.patch, > MapBuilder.java, StringUtilsAccents.patch, unaccent.patch, UnnacentMap.java > > > I would like to add a method that replace accented caracter by unaccented > one. For example, with the input String "L'été où j'ai dû aller à l'île > d'Anticosti commenca tôt", the method would return "L'ete ou j'ai du aller à > l'ile d'Anticosti commenca tot". > I suggest to call that method unaccent and to add it in StringUtils. > If we cannot covert all case, the first version could only covert iso-8859-1. > If you are willing to go forward with that idea, I am willing to contribute a > patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-285) Wish : method unaccent
[ https://issues.apache.org/jira/browse/LANG-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904146#action_12904146 ] James Carman commented on LANG-285: --- Is this code going to change when Oracle decides to change the name of the class to come.oracle.*? They've already messed up quite a few folks by changing the JVM name on their latest release from what I understand. Also, is it smart to depend on non-core classes here? What about other JVMs? Will this code not work on other JVMs? > Wish : method unaccent > -- > > Key: LANG-285 > URL: https://issues.apache.org/jira/browse/LANG-285 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Guillaume Coté >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-285-unaccent-using-Collator.patch, LANG-285.patch, > MapBuilder.java, StringUtilsAccents.patch, unaccent.patch, UnnacentMap.java > > > I would like to add a method that replace accented caracter by unaccented > one. For example, with the input String "L'été où j'ai dû aller à l'île > d'Anticosti commenca tôt", the method would return "L'ete ou j'ai du aller à > l'ile d'Anticosti commenca tot". > I suggest to call that method unaccent and to add it in StringUtils. > If we cannot covert all case, the first version could only covert iso-8859-1. > If you are willing to go forward with that idea, I am willing to contribute a > patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-641) Maven build failing --Two Junit test cases in ArrayUtilsTest giving Error
[ https://issues.apache.org/jira/browse/LANG-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved LANG-641. --- Resolution: Fixed I've made the changes. > Maven build failing --Two Junit test cases in ArrayUtilsTest giving Error > - > > Key: LANG-641 > URL: https://issues.apache.org/jira/browse/LANG-641 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: Nightly Builds > Environment: Windows Vista >Reporter: Shekhar Gulati > Fix For: Nightly Builds > > Attachments: patch_Issue-641-ArrayUtilsTest_Failure.txt > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Two unit test in ArrayUtilsTest are giving error hence the build is failing. > --- > Test set: org.apache.commons.lang3.ArrayUtilsTest > --- > Tests run: 145, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.067 sec > <<< FAILURE! > testEmptyArrayCreation(org.apache.commons.lang3.ArrayUtilsTest) Time > elapsed: 0.003 sec <<< ERROR! > java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to > [Ljava.lang.String; > at > org.apache.commons.lang3.ArrayUtilsTest.testEmptyArrayCreation(ArrayUtilsTest.java:184) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:232) > at junit.framework.TestSuite.run(TestSuite.java:227) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) > at org.apache.maven.surefire.Surefire.run(Surefire.java:180) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) > testIndirectEmptyArrayCreation(org.apache.commons.lang3.ArrayUtilsTest) Time > elapsed: 0 sec <<< ERROR! > java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to > [Ljava.lang.String; > at > org.apache.commons.lang3.ArrayUtilsTest.testIndirectEmptyArrayCreation(ArrayUtilsTest.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:232) > at junit.framework.TestSuite.run(TestSuite.java:227) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) >
[jira] Resolved: (LANG-640) Add normalizeSpace to StringUtils
[ https://issues.apache.org/jira/browse/LANG-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved LANG-640. --- Resolution: Fixed Patch applied (and simplified a bit). > Add normalizeSpace to StringUtils > - > > Key: LANG-640 > URL: https://issues.apache.org/jira/browse/LANG-640 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.0 >Reporter: Barrie Treloar >Assignee: James Carman > Fix For: 3.0 > > Attachments: LANG-640-patch.txt > > Original Estimate: 24h > Remaining Estimate: 24h > > StringUtils lacks normalizeSpace similar to > http://www.w3.org/TR/xpath/#function-normalize-space -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-640) Add normalizeSpace to StringUtils
[
https://issues.apache.org/jira/browse/LANG-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895901#action_12895901
]
James Carman edited comment on LANG-640 at 8/5/10 9:02 PM:
---
Why not just do this:
private static final Pattern WHITESPACE_BLOCK = Pattern.compile("\\s+");
public static String normalizeWhite(String input)
{
if(input == null)
{
return input;
}
return WHITESPACE_BLOCK.matcher(input.trim()).replaceAll(" ");
}
was (Author: jwcarman):
Why not use String.replaceAll("\\s+", " ")?
> Add normalizeSpace to StringUtils
> -
>
> Key: LANG-640
> URL: https://issues.apache.org/jira/browse/LANG-640
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Affects Versions: 3.0
>Reporter: Barrie Treloar
> Fix For: 3.0
>
> Attachments: LANG-640-patch.txt
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> StringUtils lacks normalizeSpace similar to
> http://www.w3.org/TR/xpath/#function-normalize-space
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-640) Add normalizeSpace to StringUtils
[
https://issues.apache.org/jira/browse/LANG-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895901#action_12895901
]
James Carman commented on LANG-640:
---
Why not use String.replaceAll("\\s+", " ")?
> Add normalizeSpace to StringUtils
> -
>
> Key: LANG-640
> URL: https://issues.apache.org/jira/browse/LANG-640
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Affects Versions: 3.0
>Reporter: Barrie Treloar
> Fix For: 3.0
>
> Attachments: LANG-640-patch.txt
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> StringUtils lacks normalizeSpace similar to
> http://www.w3.org/TR/xpath/#function-normalize-space
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-639) Compile error using ArrayUtils.add
[ https://issues.apache.org/jira/browse/LANG-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895233#action_12895233 ] James Carman commented on LANG-639: --- For issues such as this, please use commons user email list (http://commons.apache.org/lang/mail-lists.html) for support. If we determine that there is a true bug/issue with the code, we'll urge you to open up a JIRA. > Compile error using ArrayUtils.add > -- > > Key: LANG-639 > URL: https://issues.apache.org/jira/browse/LANG-639 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.5 > Environment: jdk 6 >Reporter: Zhongxian Gu > Original Estimate: 24h > Remaining Estimate: 24h > > Hi, > Sorry for bothering. I've googled it but cannot find the solution. I am new > to commons.lang. > I tried to use ArrayUtils.add(arrString, aString); but got the following > compile error. (Here arrString is a type of String[], and aString type of > String) > incompatible types > found : java.lang.Object[] > required: java.lang.String[] > String[] sa = ArrayUtils.add(arrString, aString); > I've also tried other types. All have this compile error. I don't know why. > Thanks. > Best > Zhongxian -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-580) Add Event Support Utilities
[
https://issues.apache.org/jira/browse/LANG-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman resolved LANG-580.
---
Resolution: Fixed
Patch applied, SVN revision 978864
> Add Event Support Utilities
> ---
>
> Key: LANG-580
> URL: https://issues.apache.org/jira/browse/LANG-580
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Affects Versions: 3.0
> Environment: Java SE 5.0+
>Reporter: Michael Wooten
>Assignee: James Carman
>Priority: Minor
> Fix For: 3.0
>
> Attachments: commons-lang-event-support-docs.patch,
> commons-lang-event-support.patch, commons-lang-events-merged.patch,
> commons-lang-events-package-html.txt
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> I would like to propose some support be added to Lang for basic event
> handling. This would be based on the way that PropertyChangeSupport can be
> used to add and remove listeners and post events.
> Add interface EventSupport
> addListener(L listener)
> The signature for the method that can add a listener of some subtype of
> EventListener
> removeListener(L listener)
> The signature for the method that can remove a listener of some subtype of
> EventListener
> Add class AbstractEventSupport implements EventSupport, Iterable
> AbstractEventSupport(Object eventSource)
> Constructs a new AbstractEventSupport object and associates it with the
> object that will be used as the source of all events (much like
> PropertyChangeSupport).
> addListener(L)
> An implementation that adds a listener to an internal collection.
> removeListener(L)
> An implementation that removes a listener from an internal collection.
> iterator()
> Returns an iterator over the attached listeners.
> getSource()
> Returns a reference to the source object of all events.
> The best way to describe this would be to demonstrate an example of how it
> can be used.
> public class ButtonPressedEventSupport extends
> AbstractEventSupport {
> public ButtonPressedEventSupport(Object source) { super(source); }
> public void fireButtonPressed(Button button) {
> ButtonPressedEvent bpe = new ButtonPressedEvent(getSource(), button);
> for (ButtonPressedListener listener : this)
> {
> listener.buttonPressed(bpe);
> }
> }
> }
> public class MyWindow implements EventSupport {
> private final ButtonPressedEventSupport buttonPressedEventSupport;
> public MyWindow { buttonPressedEventSupport = new
> ButtonPressedEventSupport(this); }
> public void addListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.addListener(listener); }
> public void removeListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.removeListener(listener); }
> ...
> private void onDetectButtonPressed(Button button) {
> buttonPressedEventSupport.fireButtonPressed(button);
> }
> }
> I haven't compiled the above code. It's just an example of how these classes
> could be used so that you're not constantly rewriting the code and interfaces
> for adding and removing listeners, and it provides a fairly easy method of
> creating methods to fire events.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-580) Add Event Support Utilities
[
https://issues.apache.org/jira/browse/LANG-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman resolved LANG-580.
---
Resolution: Won't Fix
We've decided to go with the EventListenerSupport concrete class instead of an
abstract class.
> Add Event Support Utilities
> ---
>
> Key: LANG-580
> URL: https://issues.apache.org/jira/browse/LANG-580
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Affects Versions: 3.0
> Environment: Java SE 5.0+
>Reporter: Michael Wooten
>Assignee: James Carman
>Priority: Minor
> Fix For: 3.0
>
> Attachments: commons-lang-event-support.patch,
> commons-lang-events-merged.patch, commons-lang-events-package-html.txt
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> I would like to propose some support be added to Lang for basic event
> handling. This would be based on the way that PropertyChangeSupport can be
> used to add and remove listeners and post events.
> Add interface EventSupport
> addListener(L listener)
> The signature for the method that can add a listener of some subtype of
> EventListener
> removeListener(L listener)
> The signature for the method that can remove a listener of some subtype of
> EventListener
> Add class AbstractEventSupport implements EventSupport, Iterable
> AbstractEventSupport(Object eventSource)
> Constructs a new AbstractEventSupport object and associates it with the
> object that will be used as the source of all events (much like
> PropertyChangeSupport).
> addListener(L)
> An implementation that adds a listener to an internal collection.
> removeListener(L)
> An implementation that removes a listener from an internal collection.
> iterator()
> Returns an iterator over the attached listeners.
> getSource()
> Returns a reference to the source object of all events.
> The best way to describe this would be to demonstrate an example of how it
> can be used.
> public class ButtonPressedEventSupport extends
> AbstractEventSupport {
> public ButtonPressedEventSupport(Object source) { super(source); }
> public void fireButtonPressed(Button button) {
> ButtonPressedEvent bpe = new ButtonPressedEvent(getSource(), button);
> for (ButtonPressedListener listener : this)
> {
> listener.buttonPressed(bpe);
> }
> }
> }
> public class MyWindow implements EventSupport {
> private final ButtonPressedEventSupport buttonPressedEventSupport;
> public MyWindow { buttonPressedEventSupport = new
> ButtonPressedEventSupport(this); }
> public void addListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.addListener(listener); }
> public void removeListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.removeListener(listener); }
> ...
> private void onDetectButtonPressed(Button button) {
> buttonPressedEventSupport.fireButtonPressed(button);
> }
> }
> I haven't compiled the above code. It's just an example of how these classes
> could be used so that you're not constantly rewriting the code and interfaces
> for adding and removing listeners, and it provides a fairly easy method of
> creating methods to fire events.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-580) Add Event Support Utilities
[
https://issues.apache.org/jira/browse/LANG-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891102#action_12891102
]
James Carman commented on LANG-580:
---
Michael,
I've committed my event support stuff to trunk. Take a look, I think you'll
like what you see. To fire events with my stuff, all you have to do is:
{code:title=MyActionListenerSource.java|borderStyle=solid}
public class MyActionListenerSource
{
EventListenerSupport listeners =
EventListenerSupport.create(ActionListener.class);
public void doSomethingCool()
{
ActionEvent e = new ActionEvent(this, ActionEvent.ACTION_PERFORMED,
"somethingCool");
listeners.fire().actionPerformed(e);
}
}
{code}
You don't have to subclass the support class, you just use it directly. This
gets rid of using the event names to fire events. You just call the event
listener methods directly yourself.
> Add Event Support Utilities
> ---
>
> Key: LANG-580
> URL: https://issues.apache.org/jira/browse/LANG-580
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Affects Versions: 3.0
> Environment: Java SE 5.0+
>Reporter: Michael Wooten
>Priority: Minor
> Fix For: 3.0
>
> Attachments: commons-lang-event-support.patch,
> commons-lang-events-package-html.txt
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> I would like to propose some support be added to Lang for basic event
> handling. This would be based on the way that PropertyChangeSupport can be
> used to add and remove listeners and post events.
> Add interface EventSupport
> addListener(L listener)
> The signature for the method that can add a listener of some subtype of
> EventListener
> removeListener(L listener)
> The signature for the method that can remove a listener of some subtype of
> EventListener
> Add class AbstractEventSupport implements EventSupport, Iterable
> AbstractEventSupport(Object eventSource)
> Constructs a new AbstractEventSupport object and associates it with the
> object that will be used as the source of all events (much like
> PropertyChangeSupport).
> addListener(L)
> An implementation that adds a listener to an internal collection.
> removeListener(L)
> An implementation that removes a listener from an internal collection.
> iterator()
> Returns an iterator over the attached listeners.
> getSource()
> Returns a reference to the source object of all events.
> The best way to describe this would be to demonstrate an example of how it
> can be used.
> public class ButtonPressedEventSupport extends
> AbstractEventSupport {
> public ButtonPressedEventSupport(Object source) { super(source); }
> public void fireButtonPressed(Button button) {
> ButtonPressedEvent bpe = new ButtonPressedEvent(getSource(), button);
> for (ButtonPressedListener listener : this)
> {
> listener.buttonPressed(bpe);
> }
> }
> }
> public class MyWindow implements EventSupport {
> private final ButtonPressedEventSupport buttonPressedEventSupport;
> public MyWindow { buttonPressedEventSupport = new
> ButtonPressedEventSupport(this); }
> public void addListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.addListener(listener); }
> public void removeListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.removeListener(listener); }
> ...
> private void onDetectButtonPressed(Button button) {
> buttonPressedEventSupport.fireButtonPressed(button);
> }
> }
> I haven't compiled the above code. It's just an example of how these classes
> could be used so that you're not constantly rewriting the code and interfaces
> for adding and removing listeners, and it provides a fairly easy method of
> creating methods to fire events.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-624) SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on Android runtime/Dalvik VM
[
https://issues.apache.org/jira/browse/LANG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890365#action_12890365
]
James Carman commented on LANG-624:
---
Agreed, Henri. If we're talking 3.0, we've got some freedom here to break some
stuff. I would think that most folks are going to check to see what
specification version is running, not what specific implementation version.
> SystemUtils.getJavaVersionAsFloat throws StringIndexOutOfBoundsException on
> Android runtime/Dalvik VM
> -
>
> Key: LANG-624
> URL: https://issues.apache.org/jira/browse/LANG-624
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Travis Truman
> Fix For: 3.0
>
> Attachments: AndriodJavaVersion.png
>
>
> Can be replicated in the Android emulator quite easily.
> Stack trace:
> {noformat}
> at
> org.apache.commons.lang.builder.ToStringBuilder.(ToStringBuilder.java:98)
> E/AndroidRuntime( 1681): ... 17 more
> E/AndroidRuntime( 1681): Caused by: java.lang.ExceptionInInitializerError
> E/AndroidRuntime( 1681): at
> org.apache.commons.lang.builder.ToStringStyle$MultiLineToStringStyle.(ToStringStyle.java:2276)
> E/AndroidRuntime( 1681): at
> org.apache.commons.lang.builder.ToStringStyle.(ToStringStyle.java:94)
> E/AndroidRuntime( 1681): ... 18 more
> E/AndroidRuntime( 1681): Caused by: java.lang.StringIndexOutOfBoundsException
> E/AndroidRuntime( 1681): at java.lang.String.substring(String.java:1571)
> E/AndroidRuntime( 1681): at
> org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat(SystemUtils.java:1153)
> E/AndroidRuntime( 1681): at
> org.apache.commons.lang.SystemUtils.(SystemUtils.java:818)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-634) StringUtils.isNumeric returns false on negative value
[
https://issues.apache.org/jira/browse/LANG-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman closed LANG-634.
-
Resolution: Won't Fix
Check the javadocs:
"Checks if the String contains only unicode digits."
This is not a bug.
> StringUtils.isNumeric returns false on negative value
> -
>
> Key: LANG-634
> URL: https://issues.apache.org/jira/browse/LANG-634
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.2
>Reporter: Arjan Moraal
>
> StringUtils.isNumeric returns false for negative values.
> So this unit test line will break the test:
> assertTrue(StringUtils.isNumeric("-1"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-634) StringUtils.isNumeric returns false on negative value
[
https://issues.apache.org/jira/browse/LANG-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888782#action_12888782
]
James Carman commented on LANG-634:
---
Try NumberUtils.isNumber().
> StringUtils.isNumeric returns false on negative value
> -
>
> Key: LANG-634
> URL: https://issues.apache.org/jira/browse/LANG-634
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.2
>Reporter: Arjan Moraal
>
> StringUtils.isNumeric returns false for negative values.
> So this unit test line will break the test:
> assertTrue(StringUtils.isNumeric("-1"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-580) Add Event Support Utilities
[
https://issues.apache.org/jira/browse/LANG-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884643#action_12884643
]
James Carman commented on LANG-580:
---
I actually have something similar to this, but I generate a proxy object to let
the user fire events. So, you'd have a method that returns "L." When the user
calls methods on that object, it would fire that event on all listeners
currently registered. It avoids the call to iterator() and encapsulates things
a bit better.
> Add Event Support Utilities
> ---
>
> Key: LANG-580
> URL: https://issues.apache.org/jira/browse/LANG-580
> Project: Commons Lang
> Issue Type: New Feature
> Components: General
>Affects Versions: 3.0
> Environment: Java SE 5.0+
>Reporter: Michael Wooten
>Priority: Minor
> Fix For: 3.0
>
> Attachments: commons-lang-event-support.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> I would like to propose some support be added to Lang for basic event
> handling. This would be based on the way that PropertyChangeSupport can be
> used to add and remove listeners and post events.
> Add interface EventSupport
> addListener(L listener)
> The signature for the method that can add a listener of some subtype of
> EventListener
> removeListener(L listener)
> The signature for the method that can remove a listener of some subtype of
> EventListener
> Add class AbstractEventSupport implements EventSupport, Iterable
> AbstractEventSupport(Object eventSource)
> Constructs a new AbstractEventSupport object and associates it with the
> object that will be used as the source of all events (much like
> PropertyChangeSupport).
> addListener(L)
> An implementation that adds a listener to an internal collection.
> removeListener(L)
> An implementation that removes a listener from an internal collection.
> iterator()
> Returns an iterator over the attached listeners.
> getSource()
> Returns a reference to the source object of all events.
> The best way to describe this would be to demonstrate an example of how it
> can be used.
> public class ButtonPressedEventSupport extends
> AbstractEventSupport {
> public ButtonPressedEventSupport(Object source) { super(source); }
> public void fireButtonPressed(Button button) {
> ButtonPressedEvent bpe = new ButtonPressedEvent(getSource(), button);
> for (ButtonPressedListener listener : this)
> {
> listener.buttonPressed(bpe);
> }
> }
> }
> public class MyWindow implements EventSupport {
> private final ButtonPressedEventSupport buttonPressedEventSupport;
> public MyWindow { buttonPressedEventSupport = new
> ButtonPressedEventSupport(this); }
> public void addListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.addListener(listener); }
> public void removeListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.removeListener(listener); }
> ...
> private void onDetectButtonPressed(Button button) {
> buttonPressedEventSupport.fireButtonPressed(button);
> }
> }
> I haven't compiled the above code. It's just an example of how these classes
> could be used so that you're not constantly rewriting the code and interfaces
> for adding and removing listeners, and it provides a fairly easy method of
> creating methods to fire events.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-618) Add an Assert class to simplify programming.
[ https://issues.apache.org/jira/browse/LANG-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857311#action_12857311 ] James Carman commented on LANG-618: --- You could also use aspects and annotations to do what you are looking to do. > Add an Assert class to simplify programming. > > > Key: LANG-618 > URL: https://issues.apache.org/jira/browse/LANG-618 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Adrian Crum >Priority: Minor > Attachments: LANG-618.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-618) Add an Assert class to simplify programming.
[ https://issues.apache.org/jira/browse/LANG-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857310#action_12857310 ] James Carman commented on LANG-618: --- What's wrong with: Validate.notNull(foo, "Argument \"foo\" cannot be null."); Validate.notNull(bar, "Argument \"bar\" cannot be null."); > Add an Assert class to simplify programming. > > > Key: LANG-618 > URL: https://issues.apache.org/jira/browse/LANG-618 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Adrian Crum >Priority: Minor > Attachments: LANG-618.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-618) Add an Assert class to simplify programming.
[ https://issues.apache.org/jira/browse/LANG-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857276#action_12857276 ] James Carman commented on LANG-618: --- Wrapper method? > Add an Assert class to simplify programming. > > > Key: LANG-618 > URL: https://issues.apache.org/jira/browse/LANG-618 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Adrian Crum >Priority: Minor > Attachments: LANG-618.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-618) Add an Assert class to simplify programming.
[ https://issues.apache.org/jira/browse/LANG-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857050#action_12857050 ] James Carman commented on LANG-618: --- Have you looked at the Validate class? http://commons.apache.org/lang/api-release/org/apache/commons/lang/Validate.html > Add an Assert class to simplify programming. > > > Key: LANG-618 > URL: https://issues.apache.org/jira/browse/LANG-618 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 3.1 >Reporter: Adrian Crum >Priority: Minor > Attachments: LANG-618.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-329) SQLException: Already closed.
[ https://issues.apache.org/jira/browse/DBCP-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851355#action_12851355 ] James Carman commented on DBCP-329: --- Wouldn't a lot of this be solved by using a validation query (and test-on-borrow)? > SQLException: Already closed. > - > > Key: DBCP-329 > URL: https://issues.apache.org/jira/browse/DBCP-329 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4 > Environment: MySQL >Reporter: Hontvari Jozsef > > After upgrading to 1.4 I see such exceptions logged: > java.sql.SQLException: Already closed. > at > org.apache.commons.dbcp.PoolableConnection.close(PoolableConnection.java:114) > at > org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:191) > ... > This should never happen. According to the Connection.close() javadoc: > "Calling the method close on a Connection object that is already closed is a > no-op." > > Moreover, I am pretty sure that our code does not close the connection twice. > But because the close() is called in a finally block, it is possible that > this exception hides another exception. Unfortunately I cannot reproduce it, > even though it occurs regularly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851068#action_12851068
]
James Carman commented on CODEC-96:
---
Use a ThreadLocal?
> Base64 encode() method is no longer thread-safe, breaking clients using it as
> a shared BinaryEncoder
>
>
> Key: CODEC-96
> URL: https://issues.apache.org/jira/browse/CODEC-96
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Matt Ryall
> Attachments: codec-96-2nd-attempt.patch
>
>
> Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
> This introduced instance variables to Base64 which means the class can no
> longer be used as a shared BinaryEncoder instance.
> For example, BinaryEncoder has an interface which could be (and was) used
> like this with Base64:
> {code:java}
> class Example {
> private BinaryEncoder encoder = new Base64();
> byte[] someMethod(byte[] data) {
> try {
> return encoder.encode(data);
> }
> catch (EncoderException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
> which is accessed by multiple threads can throw NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
> at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
> at ... (application code)
> {noformat}
> Looking at the implementation of Base64, I think making it thread-safe for
> this kind of usage would be quite tricky. I haven't attempted to prepare a
> patch.
> I would be happy if it was indicated in the Javadoc that Base64 is not
> thread-safe and should not be shared. However, some other users of
> commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIGESTER-135) Digester rules defined through Java5 Annotatations
[
https://issues.apache.org/jira/browse/DIGESTER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768293#action_12768293
]
James Carman commented on DIGESTER-135:
---
The builder API would be a chaining API like you've shown above, but I think
I'd like to introduce the idea of a "selector" for things such as text value of
the element or attribute value of an element:
builder.forPath("/persons/person").createObject(Person.class).setProperty("firstName",
attribute("fname"));
This is just off the top of my head.
> Digester rules defined through Java5 Annotatations
> --
>
> Key: DIGESTER-135
> URL: https://issues.apache.org/jira/browse/DIGESTER-135
> Project: Commons Digester
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Simone Tripodi
>Priority: Minor
> Fix For: 2.1
>
> Attachments: DigesterAnnotations.patch
>
>
> Taking inspiration by Google-Guice, JAXB and JPA's annotations, the existing
> package can be extended adding some facilities to configure the
> commons-digester using the Java language metadata annotations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIGESTER-135) Digester rules defined through Java5 Annotatations
[ https://issues.apache.org/jira/browse/DIGESTER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768263#action_12768263 ] James Carman commented on DIGESTER-135: --- It just seems way too easy to get "lost" while trying to add these annotations to your domain objects (not to mention that you're mixing XML parsing with your domain code). I'm not one of the regular committers on the Digester project, so I'll defer to their better judgement, but I'm not big on this change. Again, I would much rather see a more builder-like API for Digester rules that makes it read a little easier. > Digester rules defined through Java5 Annotatations > -- > > Key: DIGESTER-135 > URL: https://issues.apache.org/jira/browse/DIGESTER-135 > Project: Commons Digester > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Simone Tripodi >Priority: Minor > Fix For: 2.1 > > Attachments: DigesterAnnotations.patch > > > Taking inspiration by Google-Guice, JAXB and JPA's annotations, the existing > package can be extended adding some facilities to configure the > commons-digester using the Java language metadata annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIGESTER-135) Digester rules defined through Java5 Annotatations
[ https://issues.apache.org/jira/browse/DIGESTER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768240#action_12768240 ] James Carman commented on DIGESTER-135: --- I'm not so sure about this approach. One thing that jumped out at me was the @SetNext annotation. When you're building up your digester by hand, you have some context of where you are when you set up your rules. With that @SetNext, how do you know where you are? How do you know your context? It would be easy for the classes to get out of synch. I think we'd be better off creating a rules builder API that reads more like English. > Digester rules defined through Java5 Annotatations > -- > > Key: DIGESTER-135 > URL: https://issues.apache.org/jira/browse/DIGESTER-135 > Project: Commons Digester > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Simone Tripodi >Priority: Minor > Fix For: 2.1 > > Attachments: DigesterAnnotations.patch > > > Taking inspiration by Google-Guice, JAXB and JPA's annotations, the existing > package can be extended adding some facilities to configure the > commons-digester using the Java language metadata annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JEXL-54) Light performance enhancements
[
https://issues.apache.org/jira/browse/JEXL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707208#action_12707208
]
James Carman commented on JEXL-54:
--
Could JEXL benefit from JDK5+ features (most notably generics and varargs)? If
so, perhaps it's time to look at modernizing it? Is there much work going on
with JEXL?
> Light performance enhancements
> --
>
> Key: JEXL-54
> URL: https://issues.apache.org/jira/browse/JEXL-54
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Henri Biestro
> Fix For: 2.0
>
> Attachments: JEXL-54.patch
>
>
> The ClassMap.MethodCache uses String as key to methods; these keys are forged
> by concatenating the name of the method & the argument classes names
> (converted to their object equivalent for primitive types). Replacing the key
> scheme & using a dedicated class to implement the keys yields some
> performance improvement. (aka 3x faster to get from a map).
> The MethodMap uses an HashTable; by synchronizing MethodMap.{add,get} and
> synchronizing ClassMap.{get,put} on its MethodMap instance, it is possible to
> use a basic HashMap instead.
> There are various places where a StringBuffer is used when a StringBuilder
> will suffice.
> As a side note, there are a few places where the code readability can be
> improved by using strongly typed collections.
> As a small "missing" feature, exposing access to the Introspector from the
> Uberspector (Introspector getIntrospector()) allows to re-use JEXL for some
> lower level introspection needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-501) Add support for background initialization
[
https://issues.apache.org/jira/browse/LANG-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705994#action_12705994
]
James Carman commented on LANG-501:
---
I would think it'd be nice to keep the external executor "settable", so that
this thing could play nicely in Spring-based environments (you could also use
constructor-based injection I guess).
> Add support for background initialization
> -
>
> Key: LANG-501
> URL: https://issues.apache.org/jira/browse/LANG-501
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Oliver Heger
>Priority: Minor
> Fix For: 3.0
>
> Attachments: BackgroundInitializer.patch
>
>
> This is a suggestion to add a {{BackgroundInitializer}} class that allows
> initializing an object in a background task. {{BackgroundInitializer}} is a
> thin wrapper around a {{java.util.concurrent.Future}} object and uses an
> {{ExecutorService}} for starting a background task that performs
> initialization.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PROXY-8) Improve Proxy Serialization
[ https://issues.apache.org/jira/browse/PROXY-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved PROXY-8. -- Resolution: Fixed > Improve Proxy Serialization > --- > > Key: PROXY-8 > URL: https://issues.apache.org/jira/browse/PROXY-8 > Project: Commons Proxy > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1 > > > The generated proxy classes should implement serializable. Some of the > providers/invokers also should be serializable so that they can be used in > the serializable proxy objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PROXY-9) Provide Interceptor Support for More Logging Frameworks
[ https://issues.apache.org/jira/browse/PROXY-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved PROXY-9. -- Resolution: Fixed > Provide Interceptor Support for More Logging Frameworks > --- > > Key: PROXY-9 > URL: https://issues.apache.org/jira/browse/PROXY-9 > Project: Commons Proxy > Issue Type: New Feature >Affects Versions: 1.0 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1 > > > Currently, proxy only has the LoggingInterceptor which is based on Apache > Commons Logging. Please introduce new interceptors which support other > logging frameworks such as SLF4J, JCL, and JDK logging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-396) Investigate for vararg usages
[ https://issues.apache.org/jira/browse/LANG-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682144#action_12682144 ] James Carman commented on LANG-396: --- Since we're not terribly concerned with backward compatibility, can we rearrange parameters so that varargs works? Are we planning on renaming the packages? > Investigate for vararg usages > - > > Key: LANG-396 > URL: https://issues.apache.org/jira/browse/LANG-396 > Project: Commons Lang > Issue Type: Task >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: VarargsCandidates.java > > > Which methods are good candidates for varargs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-396) Investigate for vararg usages
[ https://issues.apache.org/jira/browse/LANG-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682143#action_12682143 ] James Carman commented on LANG-396: --- I can tackle these if nobody else has already started. > Investigate for vararg usages > - > > Key: LANG-396 > URL: https://issues.apache.org/jira/browse/LANG-396 > Project: Commons Lang > Issue Type: Task >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: VarargsCandidates.java > > > Which methods are good candidates for varargs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-205) Please provide simple methods for java.io.File <-> FileObject conversion
[ https://issues.apache.org/jira/browse/VFS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675648#action_12675648 ] James Carman commented on VFS-205: -- There is a utility method for converting File -> FileObject, just not back the other way (for the reasons outlined by Ralph). If you want everything to be a java.io.File object, why are you using VFS? Also, you can copy any FileObject to a File using the VFS API. That's what we do. We copy the FileObject's contents into a temp file and process it from there. > Please provide simple methods for java.io.File <-> FileObject conversion > > > Key: VFS-205 > URL: https://issues.apache.org/jira/browse/VFS-205 > Project: Commons VFS > Issue Type: Improvement >Reporter: Tim Lebedkov > > Please provide simple methods for java.io.File <-> FileObject conversion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-481) Possible race-conditions in hashCode of the range classes
[ https://issues.apache.org/jira/browse/LANG-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666915#action_12666915 ] James Carman commented on LANG-481: --- If this is indeed an issue, there are other cached values also that have the same problem (toString, maxObject, minObject) in LongRange This JIRA issue should encompass those, also. > Possible race-conditions in hashCode of the range classes > - > > Key: LANG-481 > URL: https://issues.apache.org/jira/browse/LANG-481 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Boris >Priority: Minor > > The hashCode() methods of the range classes look very suspicious to me. The > value is lazily initialized, but the calculation is done _on the cached > value. With some unlucky timing a caller may get an incomplete hash. > An unlucky sequence of Code could be something like > T1:if (hashCode == 0) // true > T1:hashCode = 17; > T2: if (hashCode == 0) // now false because hashCode was already set > to 17 > T2: return hashCode; // return 17 > T1:hashCode = 37 * hashCode... > where T1 and T2 are different threads accessing the method in parallel and T2 > gets the wrong hash "17". > Affected classes are > org.apache.commons.lang.math.DoubleRange > org.apache.commons.lang.math.FloatRange > org.apache.commons.lang.math.IntRange > org.apache.commons.lang.math.LongRange > org.apache.commons.lang.math.NumberRange > org.apache.commons.lang.math.Range > Possible fix: calculate the hash on a temporary variable and finally assign > it to the member -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-480) StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00FFFF into 2 characters
[
https://issues.apache.org/jira/browse/LANG-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666149#action_12666149
]
James Carman commented on LANG-480:
---
Of course it is. :) My point was that we would be engaging in reflection
nastiness and it might not be worth it. I would suggest that if Alexander
needs a release sooner that they do an "internal" release from the trunk with
the changes applied and then "upgrade" when we get a newer release out. I
don't like the idea of building in the reflection stuff. We get no compiler
checking that way and it leads to unreadable code.
> StringEscapeUtils.escapeHtml incorrectly converts unicode characters above
> U+00 into 2 characters
> -
>
> Key: LANG-480
> URL: https://issues.apache.org/jira/browse/LANG-480
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: doesn't matter
>Reporter: Alexander Kjäll
>Priority: Minor
> Attachments: lang-480.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Characters that are represented as a 2 characters internaly by java are
> incorrectly converted by the function. The following test displays the
> problem quite nicely:
> import org.apache.commons.lang.*;
> public class J2 {
> public static void main(String[] args) throws Exception {
> // this is the utf8 representation of the character:
> // COUNTING ROD UNIT DIGIT THREE
> // in unicode
> // codepoint: U+1D362
> byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D,
> (byte)0xA2 };
> //output is: ��
> // should be: 𝍢
> System.out.println("'" + StringEscapeUtils.escapeHtml(new
> String(data, "UTF8")) + "'");
> }
> }
> Should be very quick to fix, feel free to drop me an email if you want a
> patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-480) StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00FFFF into 2 characters
[
https://issues.apache.org/jira/browse/LANG-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665893#action_12665893
]
James Carman commented on LANG-480:
---
Wouldn't you have to use reflection, then?
> StringEscapeUtils.escapeHtml incorrectly converts unicode characters above
> U+00 into 2 characters
> -
>
> Key: LANG-480
> URL: https://issues.apache.org/jira/browse/LANG-480
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: doesn't matter
>Reporter: Alexander Kjäll
>Priority: Minor
> Attachments: lang-480.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Characters that are represented as a 2 characters internaly by java are
> incorrectly converted by the function. The following test displays the
> problem quite nicely:
> import org.apache.commons.lang.*;
> public class J2 {
> public static void main(String[] args) throws Exception {
> // this is the utf8 representation of the character:
> // COUNTING ROD UNIT DIGIT THREE
> // in unicode
> // codepoint: U+1D362
> byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D,
> (byte)0xA2 };
> //output is: ��
> // should be: 𝍢
> System.out.println("'" + StringEscapeUtils.escapeHtml(new
> String(data, "UTF8")) + "'");
> }
> }
> Should be very quick to fix, feel free to drop me an email if you want a
> patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-308) CollectionUtils.transform fails when collection is HashMap$Values
[ https://issues.apache.org/jira/browse/COLLECTIONS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659012#action_12659012 ] James Carman commented on COLLECTIONS-308: -- Do you need the transformation to be visible via the map? Or, are you just looking to take the values from the map, transform them in some way, and then do something with them? If so, then try: Collection values = new HashSet(map.values()); and play around with that values collection. Of course, you can use whatever type of collection you wish (LinkedList, ArrayList, TreeSet, etc.). > CollectionUtils.transform fails when collection is HashMap$Values > - > > Key: COLLECTIONS-308 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-308 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Affects Versions: 3.2 > Environment: Ubuntu >Reporter: Lluís Martínez >Priority: Minor > > I'm trying to apply a transformation to all values in a map : > Collection values = map.values(); > CollectionUtils.transform(values, transformer); > Gives a java.lang.UnsupportedOperationException in CollectionUtils line 439. > According to Javadoc the method values of Hashmap "does not support the add > or addAll operations.". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-472) RandomUtils.nextLong() get all even number
[
https://issues.apache.org/jira/browse/LANG-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650856#action_12650856
]
James Carman commented on LANG-472:
---
So, you're saying you never see an "ok"?
> RandomUtils.nextLong() get all even number
> --
>
> Key: LANG-472
> URL: https://issues.apache.org/jira/browse/LANG-472
> Project: Commons Lang
> Issue Type: Bug
> Environment: all system
>Reporter: zhangruimin
>
> when we use the following code , we can see that the method produce only even
> number.
> while (true) {
> //for (int i = 0; i < 100; i++) {
> if (RandomUtils.nextLong() % 2 == 1) {
> System.out.println("ok");
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-471) I would like to add isLowerCase and isUpperCase methods to WordUtils in the commons.lang package
[
https://issues.apache.org/jira/browse/LANG-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648256#action_12648256
]
James Carman commented on LANG-471:
---
Providing a proper patch (with test cases) would be a great start.
> I would like to add isLowerCase and isUpperCase methods to WordUtils in the
> commons.lang package
>
>
> Key: LANG-471
> URL: https://issues.apache.org/jira/browse/LANG-471
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivica Mikic
>Priority: Minor
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> public static boolean isLowerCase(String s)
> {
> if (s == null || s.trim().length() == 0) return false;
>
> char[] chars = new char[s.length()];
> s.getChars(0, s.length(), chars, 0);
> boolean ilc = true;
> for (int i = 0; i < chars.length; i++)
> {
> if (Character.isUpperCase(chars[i]))
> {
> ilc = false;
> break;
> }
> }
>
> return ilc;
> }
>
>
> public static boolean isUpperCase(String s)
> {
> if (s == null || s.trim().length() == 0) return false;
>
> char[] chars = new char[s.length()];
> s.getChars(0, s.length(), chars, 0);
> boolean iuc = true;
> for (int i = 0; i < chars.length; i++)
> {
> if (Character.isLowerCase(chars[i]))
> {
> iuc = false;
> break;
> }
> }
>
> return iuc;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-471) I would like to add isLowerCase and isUpperCase methods to WordUtils in the commons.lang package
[
https://issues.apache.org/jira/browse/LANG-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648219#action_12648219
]
James Carman commented on LANG-471:
---
I don't know if it belongs in WordUtils. I'd say put it in StringUtils. You
might also want to call them isAllUpperCase() or isAllLowerCase().
> I would like to add isLowerCase and isUpperCase methods to WordUtils in the
> commons.lang package
>
>
> Key: LANG-471
> URL: https://issues.apache.org/jira/browse/LANG-471
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Ivica Mikic
>Priority: Minor
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> public static boolean isLowerCase(String s)
> {
> if (s == null || s.trim().length() == 0) return false;
>
> char[] chars = new char[s.length()];
> s.getChars(0, s.length(), chars, 0);
> boolean ilc = true;
> for (int i = 0; i < chars.length; i++)
> {
> if (Character.isUpperCase(chars[i]))
> {
> ilc = false;
> break;
> }
> }
>
> return ilc;
> }
>
>
> public static boolean isUpperCase(String s)
> {
> if (s == null || s.trim().length() == 0) return false;
>
> char[] chars = new char[s.length()];
> s.getChars(0, s.length(), chars, 0);
> boolean iuc = true;
> for (int i = 0; i < chars.length; i++)
> {
> if (Character.isLowerCase(chars[i]))
> {
> iuc = false;
> break;
> }
> }
>
> return iuc;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-225) File name parsing issues in layered file systems
[ https://issues.apache.org/jira/browse/VFS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647864#action_12647864 ] James Carman commented on VFS-225: -- I wouldn't suggest writing a test case that uses "c:/" at all. Our automated builds don't run on windows machines, so those tests would fail. What's wrong with creating a ZIP file and including in as a test resource. Then use that to test the logic? > File name parsing issues in layered file systems > > > Key: VFS-225 > URL: https://issues.apache.org/jira/browse/VFS-225 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windows XP SP2 - but also assuming in other environments >Reporter: Jens Scheffler > > The "!" character is used as delimiter for e.g. ZIP file access as VFS > component. > When trying to traverse a layered file, e.g. traversing a ZIP content and the > ZIP contains a file with a "!" in the file name itself then a > FileSystemException appears - it seems that the parsing routine for layered > filenames is stumbling over the "!" character. > Exception trace for a test VFS component: > org.apache.commons.vfs.FileSystemException: Incorrect file system URI > "syncdb:file:///C:/Temp/test.xml!/c/temp/Maps/Important to Read!!/" in name > "syncdb:file:///C:/Temp/test.xml!/c/temp/Maps/Important to Read!!.txt", was > expecting "syncdb:file:///C:/Temp/test.xml!/". > at > org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:274) > at > org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:267) > at > org.apache.commons.vfs.provider.AbstractFileObject.resolveFile(AbstractFileObject.java:670) > at > de.jensscheffler.ftpsync.db.SyncFileSystemTest.treeCopy(SyncFileSystemTest.java:87) > (...) > As the accessing code was just traversing a folder tree with no chance to > handle this, is there any alternative for traversing through these layered > file systems when the content contains special characters? > Maybe the approach for parsing needs to be enhanced also, I could offer some > help but maybe need a hint to contribute a fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-469) Commons-lang StringUtils head, tail and indexOfNth (with patch)
[ https://issues.apache.org/jira/browse/LANG-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647635#action_12647635 ] James Carman commented on LANG-469: --- Can you explain what lastIndexOfNth is supposed to do (and shouldn't your parameter name be "n" and not "occurrence"?) > Commons-lang StringUtils head, tail and indexOfNth (with patch) > --- > > Key: LANG-469 > URL: https://issues.apache.org/jira/browse/LANG-469 > Project: Commons Lang > Issue Type: Improvement >Reporter: Kalecser Pasquali Kurtz >Priority: Minor > Attachments: StringUtils_head_tail_indexofnth.diff > > > Hello commons developers, > I would like to propose the addition of these four methods to StringUtils > class: > public static String head(final String str, int lines) > public static String tail(String str, int lines) > public static int indexOfNth(String str, String searchStr, int occurrence) > public static int lastIndexOfNth(String str, String searchStr, int occurrence) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-225) File name parsing issues in layered file systems
[ https://issues.apache.org/jira/browse/VFS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647508#action_12647508 ] James Carman commented on VFS-225: -- The first step would be to write up a test case that exhibits the problem. That way, we'll know if we do get it fixed. > File name parsing issues in layered file systems > > > Key: VFS-225 > URL: https://issues.apache.org/jira/browse/VFS-225 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 > Environment: Windows XP SP2 - but also assuming in other environments >Reporter: Jens Scheffler > > The "!" character is used as delimiter for e.g. ZIP file access as VFS > component. > When trying to traverse a layered file, e.g. traversing a ZIP content and the > ZIP contains a file with a "!" in the file name itself then a > FileSystemException appears - it seems that the parsing routine for layered > filenames is stumbling over the "!" character. > Exception trace for a test VFS component: > org.apache.commons.vfs.FileSystemException: Incorrect file system URI > "syncdb:file:///C:/Temp/test.xml!/c/temp/Maps/Important to Read!!/" in name > "syncdb:file:///C:/Temp/test.xml!/c/temp/Maps/Important to Read!!.txt", was > expecting "syncdb:file:///C:/Temp/test.xml!/". > at > org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:274) > at > org.apache.commons.vfs.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:267) > at > org.apache.commons.vfs.provider.AbstractFileObject.resolveFile(AbstractFileObject.java:670) > at > de.jensscheffler.ftpsync.db.SyncFileSystemTest.treeCopy(SyncFileSystemTest.java:87) > (...) > As the accessing code was just traversing a folder tree with no chance to > handle this, is there any alternative for traversing through these layered > file systems when the content contains special characters? > Maybe the approach for parsing needs to be enhanced also, I could offer some > help but maybe need a hint to contribute a fix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PROXY-11) slf4j-like discovery of the Proxy implementation to use
[ https://issues.apache.org/jira/browse/PROXY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645186#action_12645186 ] James Carman commented on PROXY-11: --- Any other thoughts on this? I don't plan on changing this paradigm until Proxy 2.0 (which will probably include some API changes also, so the build changing is the least of my worries). > slf4j-like discovery of the Proxy implementation to use > --- > > Key: PROXY-11 > URL: https://issues.apache.org/jira/browse/PROXY-11 > Project: Commons Proxy > Issue Type: Improvement >Affects Versions: 1.0 > Environment: wicket >Reporter: Johan Compagner > > I set this prio to major but for wicket it is really a blocker. In the > current state i just cant use commons proxy > I dont want in a general framework to make a decission which implementation > that i should use > Something like this should be done outside the code or at least outside my > code (that slf4j or commons logging also do) > Look at how slf4j does it because the commons logging way is a bit flawed > (classloading problems) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PROXY-14) Strategy-Based ObjectProvider
Strategy-Based ObjectProvider
-
Key: PROXY-14
URL: https://issues.apache.org/jira/browse/PROXY-14
Project: Commons Proxy
Issue Type: New Feature
Affects Versions: 1.0
Reporter: James Carman
Assignee: James Carman
Implement a strategy-based ObjectProvider. Basically, the provider would
choose different strategy objects (that implement the service interface) based
on information obtained at runtime during the method invocation. One example
would be a strategy-based provider which chose its strategy object based on the
type of object passed in as one of the method parameters (similar to HiveMind's
strategy support). For example, suppose I have a service interface like:
{code}
public interface Renderer {
public void render(Shape shape);
}
{code}
and I want to provide different implementations for Circle, Rectangle,
Triangle, etc., then I would provide a mapping from those types to
implementation objects that also implement Renderer. Proxy would create a
dynamic proxy that would choose which implementation object to use at runtime
based on the type of shape passed in to the render method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (PROXY-13) Pipeline Support
Pipeline Support Key: PROXY-13 URL: https://issues.apache.org/jira/browse/PROXY-13 Project: Commons Proxy Issue Type: New Feature Affects Versions: 1.0 Reporter: James Carman Assignee: James Carman Priority: Minor HiveMind has support for "pipelines" which consist of a series of "filters" and a "terminator." Basically, each method call goes through each filter and eventually finishes with the terminator (think Servlet filters and Servlets). This involves some pretty tricky proxy gymnastics. It would be nice if Commons Proxy supported this "out of the box." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-271) org.apache.commons.collections.ExtendedProperties#combine don't import string properly
[
https://issues.apache.org/jira/browse/COLLECTIONS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641454#action_12641454
]
James Carman commented on COLLECTIONS-271:
--
Is there a test case that shows that subset() is broken as a result of the
previously-applied patch?
> org.apache.commons.collections.ExtendedProperties#combine don't import string
> properly
> --
>
> Key: COLLECTIONS-271
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-271
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 3.2
>Reporter: Alexander Borovsky
> Fix For: 3.3
>
> Attachments: COLLECTIONS-271.patch, COLLECTIONS-271.patch, fix.patch
>
>
> When we set property with escaped characters, after combine propertySets we
> got them unescaped.
> Simple Example
> ExtendedProperties props = new ExtendedProperties();
> props.setProperty("test", "192.168.1.91test");
> props.getProperty("test"); // => \\192.168.1.91\test
> ExtendedProperties props2 = new ExtendedProperties();
> props2.combine(props);
> props.getProperty("test"); // => \192.168.1.91\test -- Wrong!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-458) Add methods to return boolean from Validate.java instead of throwing IllegalArgumentException
[
https://issues.apache.org/jira/browse/LANG-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632945#action_12632945
]
James Carman commented on LANG-458:
---
I would perhaps check out:
http://www.apache.org/foundation/how-it-works.html
to understand the "Apache Way". Basically, you start by submitting patches and
perhaps becoming active on the mailing lists. When someone on the PMC takes
notice of your contribution(s), they'll propose a vote to add you as a
committer and then let you know via email that you're "in" (if the vote passes
of course). Good luck and thanks for the interest in helping out!
> Add methods to return boolean from Validate.java instead of throwing
> IllegalArgumentException
> -
>
> Key: LANG-458
> URL: https://issues.apache.org/jira/browse/LANG-458
> Project: Commons Lang
> Issue Type: Improvement
> Environment: software
>Reporter: Viraj Turakhia
>Priority: Minor
> Attachments: code_diff.txt, test_diff.txt
>
>
> I am using Validate.java since long and find it difficult to use when I just
> want to validate collections or string.
> With current interface, I go like this:
> while(cnt < list.size()) {
> List list1 = list.get(cnt);
> try {
> Validate.notEmpty(list1);
> } catch(IllegalArgumentException e) {
> continue;
> }
> }
> much better approach is:
> while(cnt < list.size()) {
> List list1 = list.get(cnt);
> try {
> if(! Validate.notEmpty(list1)) {
> continue;
> }
> }
> If you all agree with this change, I am willing to submit a patch for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-458) Add methods to return boolean from Validate.java instead of throwing IllegalArgumentException
[
https://issues.apache.org/jira/browse/LANG-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632937#action_12632937
]
James Carman commented on LANG-458:
---
Are you an Apache Commons Committer? If not, then we can't assign it to you.
However, I would like if some other folks on the Apache Commons team would
chime in on this as to whether they think it's an appropriate addition to the
API. If they're cool with it, I have no problem applying your patch for you.
Don't worry, you'll get credit since your patch is listed here. :)
> Add methods to return boolean from Validate.java instead of throwing
> IllegalArgumentException
> -
>
> Key: LANG-458
> URL: https://issues.apache.org/jira/browse/LANG-458
> Project: Commons Lang
> Issue Type: Improvement
> Environment: software
>Reporter: Viraj Turakhia
>Priority: Minor
> Attachments: code_diff.txt, test_diff.txt
>
>
> I am using Validate.java since long and find it difficult to use when I just
> want to validate collections or string.
> With current interface, I go like this:
> while(cnt < list.size()) {
> List list1 = list.get(cnt);
> try {
> Validate.notEmpty(list1);
> } catch(IllegalArgumentException e) {
> continue;
> }
> }
> much better approach is:
> while(cnt < list.size()) {
> List list1 = list.get(cnt);
> try {
> if(! Validate.notEmpty(list1)) {
> continue;
> }
> }
> If you all agree with this change, I am willing to submit a patch for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-225) Deploy to central maven repo
[ https://issues.apache.org/jira/browse/MATH-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved MATH-225. --- Resolution: Invalid There are still a lot of issues assigned to the 2.0 release. So, it's not quite ready to go out the door (that's how it gets into the central repository). > Deploy to central maven repo > > > Key: MATH-225 > URL: https://issues.apache.org/jira/browse/MATH-225 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Brill Pappin > Fix For: 2.0 > > > Can we get this deployed lease? its a bit of a pain to have to build it > locally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MATH-225) Deploy to central maven repo
[ https://issues.apache.org/jira/browse/MATH-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed MATH-225. - > Deploy to central maven repo > > > Key: MATH-225 > URL: https://issues.apache.org/jira/browse/MATH-225 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Brill Pappin > Fix For: 2.0 > > > Can we get this deployed lease? its a bit of a pain to have to build it > locally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-458) Add methods to return boolean from Validate.java instead of throwing IllegalArgumentException
[
https://issues.apache.org/jira/browse/LANG-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630763#action_12630763
]
James Carman commented on LANG-458:
---
We couldn't use that particular API since it would break existing applications
(you can't have a method with the same name and parameter types and a different
return type). Perhaps adding a new class called Validations (Validate could be
based on it)?
\\
\\
{code}
if(!Valdations.isEmpty(list)) { continue; }
{code}
> Add methods to return boolean from Validate.java instead of throwing
> IllegalArgumentException
> -
>
> Key: LANG-458
> URL: https://issues.apache.org/jira/browse/LANG-458
> Project: Commons Lang
> Issue Type: Improvement
> Environment: software
>Reporter: Viraj Turakhia
>Priority: Minor
>
> I am using Validate.java since long and find it difficult to use when I just
> want to validate collections or string.
> With current interface, I go like this:
> while(cnt < list.size()) {
> List list1 = list.get(cnt);
> try {
> Validate.notEmpty(list1);
> } catch(IllegalArgumentException e) {
> continue;
> }
> }
> much better approach is:
> while(cnt < list.size()) {
> List list1 = list.get(cnt);
> try {
> if(! Validate.notEmpty(list1)) {
> continue;
> }
> }
> If you all agree with this change, I am willing to submit a patch for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-457) NumberUtils createNumber thows a StringIndexOutOfBoundsException when only an "l" is passed in.
[ https://issues.apache.org/jira/browse/LANG-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629275#action_12629275 ] James Carman commented on LANG-457: --- What would you rather it do? Perhaps IllegalArgumentException? > NumberUtils createNumber thows a StringIndexOutOfBoundsException when only an > "l" is passed in. > --- > > Key: LANG-457 > URL: https://issues.apache.org/jira/browse/LANG-457 > Project: Commons Lang > Issue Type: Bug >Reporter: Waldo Rochow > > Seems to be similar to LANG-300, except that if you don't place a digit in > front of the "l" or "L" it throws a StringIndexOutOfBoundsException instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626162#action_12626162 ] James Carman commented on LANG-456: --- Have you tried using UUIDs rather than basing hashCode/equals on "business" fields? > HashCodeBuilder throws StackOverflowError in bidirectional navigable > association > > > Key: LANG-456 > URL: https://issues.apache.org/jira/browse/LANG-456 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.4 > Environment: Widows XP. Sun JDK 1.5 or 1.6. >Reporter: Bob Fields > Attachments: StackOverflowError.zip > > > This is not the reflection methods, it is the regular HashCodeBuilder append > methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also > throw the StackOverflowException, but those methods work when one of the > HashCodeBuilder bidirectional association attributes .hashCode() is commented > out. The problem is that all of the builders call registerObject() which > creates a hashCode, but only the reflectionAppend method checks if an object > is registered. > Bi-directional associations are a very common pattern in Jaxb and Hibernate. > In this case, I generate code from a model in order to avoid the reflection > penalty - I already know what the attributes are at compile time, so I use > .append instead of .reflectionAppend. > See attached example + unit test. One side of the bidirectional association > must be commented out in the hashCode method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-455) New TimeoutProcessBuilder class
[ https://issues.apache.org/jira/browse/LANG-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623115#action_12623115 ] James Carman commented on LANG-455: --- Would this be better suited for the commons-exec project? > New TimeoutProcessBuilder class > --- > > Key: LANG-455 > URL: https://issues.apache.org/jira/browse/LANG-455 > Project: Commons Lang > Issue Type: New Feature >Reporter: Jeff Rodriguez >Priority: Minor > Attachments: TimeoutProcessBuilder.java > > Original Estimate: 2h > Remaining Estimate: 2h > > I've a new class I would like to contribute to Commons Lang. It's purpose is > to safely waitFor() processes created with a ProcessBuilder to exit. By > safely I mean a timeout is instituted. > It will need to be updated to use Commons Lang code style and package name > space, as well as have a test case written for it. I'm not sure how that > should work given it's platform specific nature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-169) Thrown exception reveals passwords
[ https://issues.apache.org/jira/browse/VFS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619478#action_12619478 ] James Carman commented on VFS-169: -- "I hope you fix this soon" That's the beauty of open source software; you can help fix this! Attaching a patch (including test cases) would be a good way to help get this thing fixed. It seems like you've already got a good idea about how it should be done. > Thrown exception reveals passwords > -- > > Key: VFS-169 > URL: https://issues.apache.org/jira/browse/VFS-169 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Joerg Schaible > > If an exception occurs accessing a FileObject on a FileSystem that is > addressed with an URL containing user and password the thrown exception > contains the password as part of the error message: > org.apache.commons.vfs.FileSystemException: Could not connect to SFTP server > at "sftp://user:[EMAIL PROTECTED]/". > In such a case the URL should be printed as "sftp://user:[EMAIL PROTECTED]/". > Same applied to log messages - at least for INFO and higher. > This is a security risk, since in big companies exceptions and logs are > normally collected and archived in monitoring systems and may reveal the > password to persons that have normally no authorization to the target system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-452) ObjectUtils.toString() should return constant empty String from StringUtils:EMPTY instead a new Empty String
[
https://issues.apache.org/jira/browse/LANG-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman resolved LANG-452.
---
Resolution: Invalid
Assignee: James Carman
> ObjectUtils.toString() should return constant empty String from
> StringUtils:EMPTY instead a new Empty String
>
>
> Key: LANG-452
> URL: https://issues.apache.org/jira/browse/LANG-452
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Conny Kreyßel
>Assignee: James Carman
>
> In commons-lang 2.4 the method
> public static String toString(Object obj) {
> return obj == null ? "" : obj.toString();
> }
> every call a new emptyb String.
> Is it possible to change it to
> public static String toString(Object obj) {
> return obj == null ? StringUtils.EMPTY : obj.toString();
> }
> ???
> This change saves IMHO resources?!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-452) ObjectUtils.toString() should return constant empty String from StringUtils:EMPTY instead a new Empty String
[
https://issues.apache.org/jira/browse/LANG-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617476#action_12617476
]
James Carman commented on LANG-452:
---
This wouldn't be a new String instance. This is the empty string literal. All
literals will refer to the same object. Try it out:
{code}
System.out.println("" == StringUtils.EMPTY);
{code}
> ObjectUtils.toString() should return constant empty String from
> StringUtils:EMPTY instead a new Empty String
>
>
> Key: LANG-452
> URL: https://issues.apache.org/jira/browse/LANG-452
> Project: Commons Lang
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Conny Kreyßel
>
> In commons-lang 2.4 the method
> public static String toString(Object obj) {
> return obj == null ? "" : obj.toString();
> }
> every call a new emptyb String.
> Is it possible to change it to
> public static String toString(Object obj) {
> return obj == null ? StringUtils.EMPTY : obj.toString();
> }
> ???
> This change saves IMHO resources?!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-451) isWhitespace returns true for empty ("") strings.
[
https://issues.apache.org/jira/browse/LANG-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman resolved LANG-451.
---
Resolution: Invalid
Assignee: James Carman
The Javadocs specifically state that the method will return true for empty
strings. This is the intended behavior.
> isWhitespace returns true for empty ("") strings.
> -
>
> Key: LANG-451
> URL: https://issues.apache.org/jira/browse/LANG-451
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: windows xp/java 1.5.0.12
>Reporter: Ryan Ovrevik
>Assignee: James Carman
>Priority: Minor
>
> if (StringUtils.isWhitespace("") == true) {
> //seems wrong
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-226) Endless loop listing files on Windows NT FTP-Server
[ https://issues.apache.org/jira/browse/NET-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612232#action_12612232 ] James Carman commented on NET-226: -- I would maybe try upgrading to the newer VFS (if you haven't already). I believe it tries to minimize all of those calls to resolve the file objects. > Endless loop listing files on Windows NT FTP-Server > --- > > Key: NET-226 > URL: https://issues.apache.org/jira/browse/NET-226 > Project: Commons Net > Issue Type: Bug >Affects Versions: 1.4 > Environment: VFS client on linux machine connecting to a Windows-NT > ftp server using unix file listing >Reporter: Frederic Müller >Priority: Blocker > > The framework repeatedly queries the contents of a remote ftp folder as well > it's parent folder. It will do so indefinitely. Other ftp software can access > the server without problems. I implemented a new class extending the > UnixFTPEntryParser to intercept the requests and to print the following stack > traces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (BEANUTILS-321) [beanutils] wont recognize isXXX() properties returning Boolean Object
[
https://issues.apache.org/jira/browse/BEANUTILS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612097#action_12612097
]
jwcarman edited comment on BEANUTILS-321 at 7/9/08 6:35 AM:
Thomas,
If you do something like:
{code}
if(myBean.isBooleanClass())
{
// Do something here...
}
{code}
and the Boolean type booleanClass member variable is null, you'll get a null
pointer in JDK5+, because the auto-unboxing feature tries to call
booleanClass.booleanValue() to unbox it. If you try to do this in pre-JD5, it
won't compile (because Boolean isn't of type boolean, so you can't use it as
your conditional in your if statement).
And, for the record, I do understand your point. I've actually encountered
this before. I don't recall the exact situation, but I'm sure I just renamed
my "getter." Have you tried providing a "get" version of your accessor along
with the "is" version? That should probably solve your problem, I think (if
you're ok with the potential NPE when accessing the "is" version in a
conditional that is).
was (Author: jwcarman):
Thomas,
If you do something like:
{code}
if(myBean.isBooleanClass())
{
// Do something here...
}
{code}
and the Boolean type booleanClass member variable is null, you'll get a null
pointer in JDK5+, because the auto-unboxing feature tries to call
booleanClass.booleanValue() to unbox it. If you try to do this in pre-JD5, it
won't compile (because Boolean isn't of type boolean, so you can't use it as
your conditional in your if statement)
> [beanutils] wont recognize isXXX() properties returning Boolean Object
> --
>
> Key: BEANUTILS-321
> URL: https://issues.apache.org/jira/browse/BEANUTILS-321
> Project: Commons BeanUtils
> Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: thomas menzel
>
> it seems that an isXXX() style property returning an java.lang.Boolean Object
> is NOT recognized as the getter peoperty -- at least it wont copy it.
> Hence, the test case below will fail.
> I suggest to handle these props as well, as for a user of BeanUtils this
> was/is quite surprising to me -- and probably others.
> Thx
> {code:java}
> /**
> * @author tmenzel
> *
> */
> public class BeanUtilsTest extends TestCase {
> private class FooBean {
> Boolean booleanClass;
> boolean booleanPrimitive;
> public Boolean isBooleanClass() {
> return booleanClass;
> }
> public void setBooleanClass(Boolean booleanClass) {
> this.booleanClass = booleanClass;
> }
> public boolean isBooleanPrimitive() {
> return booleanPrimitive;
> }
> public void setBooleanPrimitive(boolean booleanPrimitive) {
> this.booleanPrimitive = booleanPrimitive;
> }
> }
> public void testCopyBooleanProps() throws Exception {
> FooBean a = new FooBean();
> a.setBooleanClass(false);
> a.setBooleanPrimitive(false);
> FooBean b = new FooBean();
> b.setBooleanClass(true);
> b.setBooleanPrimitive(true);
> BeanUtils.copyProperties(a, b);
> assertEquals(a.isBooleanPrimitive(), b.isBooleanPrimitive());
> assertEquals(a.isBooleanClass(), b.isBooleanClass());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-321) [beanutils] wont recognize isXXX() properties returning Boolean Object
[
https://issues.apache.org/jira/browse/BEANUTILS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612104#action_12612104
]
James Carman commented on BEANUTILS-321:
Paul,
My point exactly. A Boolean isn't binary; it's ternary, so that's probably why
they didn't include it in the spec, since it's not an is or is not situation.
> [beanutils] wont recognize isXXX() properties returning Boolean Object
> --
>
> Key: BEANUTILS-321
> URL: https://issues.apache.org/jira/browse/BEANUTILS-321
> Project: Commons BeanUtils
> Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: thomas menzel
>
> it seems that an isXXX() style property returning an java.lang.Boolean Object
> is NOT recognized as the getter peoperty -- at least it wont copy it.
> Hence, the test case below will fail.
> I suggest to handle these props as well, as for a user of BeanUtils this
> was/is quite surprising to me -- and probably others.
> Thx
> {code:java}
> /**
> * @author tmenzel
> *
> */
> public class BeanUtilsTest extends TestCase {
> private class FooBean {
> Boolean booleanClass;
> boolean booleanPrimitive;
> public Boolean isBooleanClass() {
> return booleanClass;
> }
> public void setBooleanClass(Boolean booleanClass) {
> this.booleanClass = booleanClass;
> }
> public boolean isBooleanPrimitive() {
> return booleanPrimitive;
> }
> public void setBooleanPrimitive(boolean booleanPrimitive) {
> this.booleanPrimitive = booleanPrimitive;
> }
> }
> public void testCopyBooleanProps() throws Exception {
> FooBean a = new FooBean();
> a.setBooleanClass(false);
> a.setBooleanPrimitive(false);
> FooBean b = new FooBean();
> b.setBooleanClass(true);
> b.setBooleanPrimitive(true);
> BeanUtils.copyProperties(a, b);
> assertEquals(a.isBooleanPrimitive(), b.isBooleanPrimitive());
> assertEquals(a.isBooleanClass(), b.isBooleanClass());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-321) [beanutils] wont recognize isXXX() properties returning Boolean Object
[
https://issues.apache.org/jira/browse/BEANUTILS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612097#action_12612097
]
James Carman commented on BEANUTILS-321:
Thomas,
If you do something like:
{code}
if(myBean.isBooleanClass())
{
// Do something here...
}
{code}
and the Boolean type booleanClass member variable is null, you'll get a null
pointer in JDK5+, because the auto-unboxing feature tries to call
booleanClass.booleanValue() to unbox it. If you try to do this in pre-JD5, it
won't compile (because Boolean isn't of type boolean, so you can't use it as
your conditional in your if statement)
> [beanutils] wont recognize isXXX() properties returning Boolean Object
> --
>
> Key: BEANUTILS-321
> URL: https://issues.apache.org/jira/browse/BEANUTILS-321
> Project: Commons BeanUtils
> Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: thomas menzel
>
> it seems that an isXXX() style property returning an java.lang.Boolean Object
> is NOT recognized as the getter peoperty -- at least it wont copy it.
> Hence, the test case below will fail.
> I suggest to handle these props as well, as for a user of BeanUtils this
> was/is quite surprising to me -- and probably others.
> Thx
> {code:java}
> /**
> * @author tmenzel
> *
> */
> public class BeanUtilsTest extends TestCase {
> private class FooBean {
> Boolean booleanClass;
> boolean booleanPrimitive;
> public Boolean isBooleanClass() {
> return booleanClass;
> }
> public void setBooleanClass(Boolean booleanClass) {
> this.booleanClass = booleanClass;
> }
> public boolean isBooleanPrimitive() {
> return booleanPrimitive;
> }
> public void setBooleanPrimitive(boolean booleanPrimitive) {
> this.booleanPrimitive = booleanPrimitive;
> }
> }
> public void testCopyBooleanProps() throws Exception {
> FooBean a = new FooBean();
> a.setBooleanClass(false);
> a.setBooleanPrimitive(false);
> FooBean b = new FooBean();
> b.setBooleanClass(true);
> b.setBooleanPrimitive(true);
> BeanUtils.copyProperties(a, b);
> assertEquals(a.isBooleanPrimitive(), b.isBooleanPrimitive());
> assertEquals(a.isBooleanClass(), b.isBooleanClass());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-321) [beanutils] wont recognize isXXX() properties returning Boolean Object
[
https://issues.apache.org/jira/browse/BEANUTILS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612015#action_12612015
]
James Carman commented on BEANUTILS-321:
By the way, this is mentioned in the API documentation (albeit in a somewhat
roundabout way). The BeanUtils class uses a PropertyUtilsBean:
http://commons.apache.org/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/PropertyUtilsBean.html
"The name of the actual getter or setter method to be used is determined using
standard JavaBeans instrospection, so that (unless overridden by a BeanInfo
class, a property named "xyz" will have a getter method named getXyz() or (*for
boolean properties only*) isXyz(), and a setter method named setXyz()."
> [beanutils] wont recognize isXXX() properties returning Boolean Object
> --
>
> Key: BEANUTILS-321
> URL: https://issues.apache.org/jira/browse/BEANUTILS-321
> Project: Commons BeanUtils
> Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: thomas menzel
>
> it seems that an isXXX() style property returning an java.lang.Boolean Object
> is NOT recognized as the getter peoperty -- at least it wont copy it.
> Hence, the test case below will fail.
> I suggest to handle these props as well, as for a user of BeanUtils this
> was/is quite surprising to me -- and probably others.
> Thx
> {code:java}
> /**
> * @author tmenzel
> *
> */
> public class BeanUtilsTest extends TestCase {
> private class FooBean {
> Boolean booleanClass;
> boolean booleanPrimitive;
> public Boolean isBooleanClass() {
> return booleanClass;
> }
> public void setBooleanClass(Boolean booleanClass) {
> this.booleanClass = booleanClass;
> }
> public boolean isBooleanPrimitive() {
> return booleanPrimitive;
> }
> public void setBooleanPrimitive(boolean booleanPrimitive) {
> this.booleanPrimitive = booleanPrimitive;
> }
> }
> public void testCopyBooleanProps() throws Exception {
> FooBean a = new FooBean();
> a.setBooleanClass(false);
> a.setBooleanPrimitive(false);
> FooBean b = new FooBean();
> b.setBooleanClass(true);
> b.setBooleanPrimitive(true);
> BeanUtils.copyProperties(a, b);
> assertEquals(a.isBooleanPrimitive(), b.isBooleanPrimitive());
> assertEquals(a.isBooleanClass(), b.isBooleanClass());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-321) [beanutils] wont recognize isXXX() properties returning Boolean Object
[
https://issues.apache.org/jira/browse/BEANUTILS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612011#action_12612011
]
James Carman commented on BEANUTILS-321:
How are you getting classes that have Boolean properties set up with "is"
accessor methods (IDEs don't generate them that way)? This can be dangerous,
especially with autoboxing (or autounboxing rather), because if the value us
null, you'll get a NPE. If it truly is a binary sort of situation (either it
is or it isn't) then you should use boolean, since Boolean is actually somewhat
ternary (true, false, null).
> [beanutils] wont recognize isXXX() properties returning Boolean Object
> --
>
> Key: BEANUTILS-321
> URL: https://issues.apache.org/jira/browse/BEANUTILS-321
> Project: Commons BeanUtils
> Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: thomas menzel
>
> it seems that an isXXX() style property returning an java.lang.Boolean Object
> is NOT recognized as the getter peoperty -- at least it wont copy it.
> Hence, the test case below will fail.
> I suggest to handle these props as well, as for a user of BeanUtils this
> was/is quite surprising to me -- and probably others.
> Thx
> {code:java}
> /**
> * @author tmenzel
> *
> */
> public class BeanUtilsTest extends TestCase {
> private class FooBean {
> Boolean booleanClass;
> boolean booleanPrimitive;
> public Boolean isBooleanClass() {
> return booleanClass;
> }
> public void setBooleanClass(Boolean booleanClass) {
> this.booleanClass = booleanClass;
> }
> public boolean isBooleanPrimitive() {
> return booleanPrimitive;
> }
> public void setBooleanPrimitive(boolean booleanPrimitive) {
> this.booleanPrimitive = booleanPrimitive;
> }
> }
> public void testCopyBooleanProps() throws Exception {
> FooBean a = new FooBean();
> a.setBooleanClass(false);
> a.setBooleanPrimitive(false);
> FooBean b = new FooBean();
> b.setBooleanClass(true);
> b.setBooleanPrimitive(true);
> BeanUtils.copyProperties(a, b);
> assertEquals(a.isBooleanPrimitive(), b.isBooleanPrimitive());
> assertEquals(a.isBooleanClass(), b.isBooleanClass());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-321) [beanutils] wont recognize isXXX() properties returning Boolean Object
[
https://issues.apache.org/jira/browse/BEANUTILS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611990#action_12611990
]
James Carman commented on BEANUTILS-321:
This is because the JavaBeans specification doesn't say that Boolean properties
can have "is" accessor methods, only boolean properties. See the JavaBeans
specification section 8.3.2.
http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html
> [beanutils] wont recognize isXXX() properties returning Boolean Object
> --
>
> Key: BEANUTILS-321
> URL: https://issues.apache.org/jira/browse/BEANUTILS-321
> Project: Commons BeanUtils
> Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: thomas menzel
>
> it seems that an isXXX() style property returning an java.lang.Boolean Object
> is NOT recognized as the getter peoperty -- at least it wont copy it.
> Hence, the test case below will fail.
> I suggest to handle these props as well, as for a user of BeanUtils this
> was/is quite surprising to me -- and probably others.
> Thx
> {code:java}
> /**
> * @author tmenzel
> *
> */
> public class BeanUtilsTest extends TestCase {
> private class FooBean {
> Boolean booleanClass;
> boolean booleanPrimitive;
> public Boolean isBooleanClass() {
> return booleanClass;
> }
> public void setBooleanClass(Boolean booleanClass) {
> this.booleanClass = booleanClass;
> }
> public boolean isBooleanPrimitive() {
> return booleanPrimitive;
> }
> public void setBooleanPrimitive(boolean booleanPrimitive) {
> this.booleanPrimitive = booleanPrimitive;
> }
> }
> public void testCopyBooleanProps() throws Exception {
> FooBean a = new FooBean();
> a.setBooleanClass(false);
> a.setBooleanPrimitive(false);
> FooBean b = new FooBean();
> b.setBooleanClass(true);
> b.setBooleanPrimitive(true);
> BeanUtils.copyProperties(a, b);
> assertEquals(a.isBooleanPrimitive(), b.isBooleanPrimitive());
> assertEquals(a.isBooleanClass(), b.isBooleanClass());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-222) Implement threadsafety annotations: @ThreadSafe, @Immutable etc
[ https://issues.apache.org/jira/browse/NET-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609586#action_12609586 ] James Carman commented on NET-222: -- If this would introduce another runtime dependency, I'd say this is probably not a good idea. > Implement threadsafety annotations: @ThreadSafe, @Immutable etc > --- > > Key: NET-222 > URL: https://issues.apache.org/jira/browse/NET-222 > Project: Commons Net > Issue Type: Wish >Reporter: Sebb > Fix For: 2.1 > > > It would be very helpful for maintaing and checking code if the classes and > fields were updated with the thread-safety annotations: > @Immutable > @Threadsafe > @NotThreadsafe > @GuardedBy > These can be used by tools such as Findbugs to check that code conforms to > the annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-300) Method to query Class to determine if it is a collection
[ https://issues.apache.org/jira/browse/COLLECTIONS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608863#action_12608863 ] James Carman commented on COLLECTIONS-300: -- So, you want something that says "does this class implement java.util.Collection or java.util.Map or ..."? > Method to query Class to determine if it is a collection > > > Key: COLLECTIONS-300 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-300 > Project: Commons Collections > Issue Type: Wish >Reporter: Paul Benedict >Priority: Minor > Fix For: 3.3 > > > Test a Class instance to determine whether it is a known JDK collection type. > Someone else should opine if other Apache Collection interfaces should be > included in the same or different method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605683#action_12605683
]
James Carman commented on LANG-425:
---
I thought we just voted to make commons lang JDK5-dependent (for 3.x releases)?
> Sequence(String)Utils
> -
>
> Key: LANG-425
> URL: https://issues.apache.org/jira/browse/LANG-425
> Project: Commons Lang
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Robert Scholte
>Priority: Trivial
>
> Don't you think it's kind of strange to have RandomUtils and
> RandomStringUtils, but not just the ordinairy SequenceUtils?
> I've seen commons-id in the sandbox, but maybe some basics should become part
> of commons lang.
> Most classes of within this package are stateless/static, or they have a
> state within a method (such as StrBuilder). SequenceUtils can only be static,
> if it has the startValue.
> For example
> {code}
> SequenceUtils.nextInt(10)
> SequenceUtils.nextString("MORE")
> SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
> SequenceUtils.nextString("C0DE", "0123456789ABCDEF") //next hexadecimal
> {code}
> any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605622#action_12605622
]
James Carman commented on LANG-425:
---
Perhaps we come up with a generified interface? Something like:
{code}
public interface Sequence
{
public T nextValue();
}
{code}
This just sounds a lot like Iterator, though except the idea of hasNext()
might not be applicable here. To adapt a Sequence to the Iterator interface we
could do:
{code}
public class SequenceIterator implements Iterator
{
private final Sequence sequence;
public T next()
{
return sequence.nextValue();
}
public boolean hasNext()
{
return true;
}
}
{code}
Thus, if code needs a sequence of Integers (or ints with autoboxing), they
would declare their API with Sequence. If they need a sequence of
strings, they would do Sequence.
> Sequence(String)Utils
> -
>
> Key: LANG-425
> URL: https://issues.apache.org/jira/browse/LANG-425
> Project: Commons Lang
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Robert Scholte
>Priority: Trivial
>
> Don't you think it's kind of strange to have RandomUtils and
> RandomStringUtils, but not just the ordinairy SequenceUtils?
> I've seen commons-id in the sandbox, but maybe some basics should become part
> of commons lang.
> Most classes of within this package are stateless/static, or they have a
> state within a method (such as StrBuilder). SequenceUtils can only be static,
> if it has the startValue.
> For example
> {code}
> SequenceUtils.nextInt(10)
> SequenceUtils.nextString("MORE")
> SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
> SequenceUtils.nextString("C0DE", "0123456789ABCDEF") //next hexadecimal
> {code}
> any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (VFS-211) The SFTP Provider Should Use Daemon Threads
[ https://issues.apache.org/jira/browse/VFS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed VFS-211. This appears to have fixed the issue in our application, so I'm closing the issue. > The SFTP Provider Should Use Daemon Threads > --- > > Key: VFS-211 > URL: https://issues.apache.org/jira/browse/VFS-211 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.1, 2.0 >Reporter: James Carman >Assignee: James Carman > Fix For: 2.0 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > In a simple connect and list the contents example, it never terminates since > JSch fires up a "keep alive" thread and doesn't mark it as daemon. You can > tell JSch to make that thread a daemon thread by calling > setDaemonThread(true) on the Session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-211) The SFTP Provider Should Use Daemon Threads
[ https://issues.apache.org/jira/browse/VFS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved VFS-211. -- Resolution: Fixed > The SFTP Provider Should Use Daemon Threads > --- > > Key: VFS-211 > URL: https://issues.apache.org/jira/browse/VFS-211 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.1, 2.0 >Reporter: James Carman >Assignee: James Carman > Fix For: 2.0 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > In a simple connect and list the contents example, it never terminates since > JSch fires up a "keep alive" thread and doesn't mark it as daemon. You can > tell JSch to make that thread a daemon thread by calling > setDaemonThread(true) on the Session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (VFS-211) The SFTP Provider Should Use Daemon Threads
The SFTP Provider Should Use Daemon Threads --- Key: VFS-211 URL: https://issues.apache.org/jira/browse/VFS-211 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.1, 2.0 Reporter: James Carman Assignee: James Carman Fix For: 2.0 In a simple connect and list the contents example, it never terminates since JSch fires up a "keep alive" thread and doesn't mark it as daemon. You can tell JSch to make that thread a daemon thread by calling setDaemonThread(true) on the Session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PROXY-12) ChainInvoker
[ https://issues.apache.org/jira/browse/PROXY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved PROXY-12. --- Resolution: Fixed > ChainInvoker > > > Key: PROXY-12 > URL: https://issues.apache.org/jira/browse/PROXY-12 > Project: Commons Proxy > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1 > > Original Estimate: 2h > Remaining Estimate: 2h > > Implement a "chain" invoker. The invoker should invoke a method on a series > of targets. If one of the targets returns a non-default value, return it. > Otherwise, return the default value for the method's return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (PROXY-12) ChainInvoker
[ https://issues.apache.org/jira/browse/PROXY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed PROXY-12. - > ChainInvoker > > > Key: PROXY-12 > URL: https://issues.apache.org/jira/browse/PROXY-12 > Project: Commons Proxy > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1 > > Original Estimate: 2h > Remaining Estimate: 2h > > Implement a "chain" invoker. The invoker should invoke a method on a series > of targets. If one of the targets returns a non-default value, return it. > Otherwise, return the default value for the method's return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PROXY-12) ChainInvoker
ChainInvoker Key: PROXY-12 URL: https://issues.apache.org/jira/browse/PROXY-12 Project: Commons Proxy Issue Type: New Feature Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1 Implement a "chain" invoker. The invoker should invoke a method on a series of targets. If one of the targets returns a non-default value, return it. Otherwise, return the default value for the method's return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[
https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599587#action_12599587
]
James Carman commented on VFS-196:
--
There were some changes to the logic in trunk from when I created this patch.
The trunk had:
\\
\\
{code}
final FTPFile[] tmpChildren = client.listFiles(relPath);
if (tmpChildren == null)
{
children = null;
}
else if (tmpChildren.length == 0)
{
children = EMPTY_FTP_FILE_MAP;
}
else
{
children = new TreeMap();
...
{code}
\\
and my code has:
\\
\\
{code}
final String path = fileInfo != null && fileInfo.isSymbolicLink() ?
getFileSystem().getFileSystemManager().resolveName(getParent().getName(),
fileInfo.getLink() ).getPath() : relPath;
final FTPFile[] tmpChildren = client.listFiles(path);
if (tmpChildren == null || tmpChildren.length == 0)
{
children = EMPTY_FTP_FILE_MAP;
}
else
{
children = new TreeMap();
...
{code}
\\
I don't know if the null case is handled correctly or not. Please advise.
> FTP Provider Does Not Support Symbolic Links Correctly
> --
>
> Key: VFS-196
> URL: https://issues.apache.org/jira/browse/VFS-196
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: James Carman
>Assignee: James Carman
> Fix For: 1.1, 2.0
>
> Attachments: symbolic_links.patch
>
>
> If a directory is a symbolic link, it shows up as file type "imaginary"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved VFS-196. -- Resolution: Fixed Fix Version/s: 2.0 The patch has been applied to both trunk and the version 1 branch. I did not include a unit test for this, as I am unfamiliar with how you do unit testing in VFS. We have however, used this patch in our local version for quite some time and it seems to work just fine. > FTP Provider Does Not Support Symbolic Links Correctly > -- > > Key: VFS-196 > URL: https://issues.apache.org/jira/browse/VFS-196 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1, 2.0 > > Attachments: symbolic_links.patch > > > If a directory is a symbolic link, it shows up as file type "imaginary" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (VFS-197) Maven2 Build Fails
[ https://issues.apache.org/jira/browse/VFS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed VFS-197. > Maven2 Build Fails > -- > > Key: VFS-197 > URL: https://issues.apache.org/jira/browse/VFS-197 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1, 2.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > On my machine, the maven2 build fails with the following exception: > --- > Test set: org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase > --- > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec <<< > FAILURE! > testDefaultInstance(org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase) > Time elapsed: 0.018 sec <<< FAILURE! > junit.framework.AssertionFailedError: Test file > "C:\Users\jcarman\IdeaProjects\commons-vfs-clean\core\target\test-classes\test-data\test.jar" > does not exist. > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:85) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:71) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > The problem is that the maven build isn't copying the test data over into the > target folder. I can fix this, but it will mean moving the test data around > a bit by putting it in the src/main/resources (the standard place for testing > resources for m2). I'll attach a patch illustrating my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (VFS-197) Maven2 Build Fails
[ https://issues.apache.org/jira/browse/VFS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman resolved VFS-197. -- Resolution: Fixed Fix Version/s: 2.0 I applied this change to both the version 1 branch and the main trunk. > Maven2 Build Fails > -- > > Key: VFS-197 > URL: https://issues.apache.org/jira/browse/VFS-197 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1, 2.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > On my machine, the maven2 build fails with the following exception: > --- > Test set: org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase > --- > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec <<< > FAILURE! > testDefaultInstance(org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase) > Time elapsed: 0.018 sec <<< FAILURE! > junit.framework.AssertionFailedError: Test file > "C:\Users\jcarman\IdeaProjects\commons-vfs-clean\core\target\test-classes\test-data\test.jar" > does not exist. > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:85) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:71) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > The problem is that the maven build isn't copying the test data over into the > target folder. I can fix this, but it will mean moving the test data around > a bit by putting it in the src/main/resources (the standard place for testing > resources for m2). I'll attach a patch illustrating my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-210) Wrapper-Mode VFS
[ https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599579#action_12599579 ] James Carman commented on VFS-210: -- We basically use it as a "shared drive" implementation. Our application needs to be able to move files around when the user needs them. So, we use VFS as an abstraction so we can change the implementation (we currently use WebDAV) if we want to. We really love the VFS API for this! Thanks for all your hard work! > Wrapper-Mode VFS > > > Key: VFS-210 > URL: https://issues.apache.org/jira/browse/VFS-210 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Mario Ivankovits >Assignee: Mario Ivankovits > Fix For: 2.0 > > > VFS should behave more like a wrapper to the underlaying library than a full > blown filesystem. > This should solve the following problems: > * access of hidden files/directories > * access to special folders > * speed up FTP access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-197) Maven2 Build Fails
[ https://issues.apache.org/jira/browse/VFS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599576#action_12599576 ] James Carman commented on VFS-197: -- Alternatively, we can add a test resources section to VFS' pom.xml file saying that it should copy all non-java files in its src/test/java directory as test resources. Would you like me to attach a patch? > Maven2 Build Fails > -- > > Key: VFS-197 > URL: https://issues.apache.org/jira/browse/VFS-197 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman > Fix For: 1.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > On my machine, the maven2 build fails with the following exception: > --- > Test set: org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase > --- > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec <<< > FAILURE! > testDefaultInstance(org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase) > Time elapsed: 0.018 sec <<< FAILURE! > junit.framework.AssertionFailedError: Test file > "C:\Users\jcarman\IdeaProjects\commons-vfs-clean\core\target\test-classes\test-data\test.jar" > does not exist. > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:85) > at > org.apache.commons.AbstractVfsTestCase.getTestResource(AbstractVfsTestCase.java:71) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at > org.apache.commons.vfs.test.FileSystemManagerFactoryTestCase.testDefaultInstance(FileSystemManagerFactoryTestCase.java:45) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > The problem is that the maven build isn't copying the test data over into the > target folder. I can fix this, but it will mean moving the test data around > a bit by putting it in the src/main/resources (the standard place for testing > resources for m2). I'll attach a patch illustrating my changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599575#action_12599575 ] James Carman commented on VFS-196: -- Mario, Do you want me to just apply this patch or would you like to check it out first? James > FTP Provider Does Not Support Symbolic Links Correctly > -- > > Key: VFS-196 > URL: https://issues.apache.org/jira/browse/VFS-196 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 1.1 >Reporter: James Carman >Assignee: James Carman > Fix For: 1.1 > > Attachments: symbolic_links.patch > > > If a directory is a symbolic link, it shows up as file type "imaginary" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-210) Wrapper-Mode VFS
[ https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599573#action_12599573 ] James Carman commented on VFS-210: -- We're still going to maintain the common API, right? So, I can treat an FTP file object the same as a WebDAV file object? I've got code that relies upon that abstraction and it works very nicely. We just use a regular disk file during unit testing and we use WebDAV in "production" with no changes to the code (just configuration). > Wrapper-Mode VFS > > > Key: VFS-210 > URL: https://issues.apache.org/jira/browse/VFS-210 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Mario Ivankovits >Assignee: Mario Ivankovits > Fix For: 2.0 > > > VFS should behave more like a wrapper to the underlaying library than a full > blown filesystem. > This should solve the following problems: > * access of hidden files/directories > * access to special folders > * speed up FTP access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592589#action_12592589
]
James Carman commented on LANG-425:
---
I like the idea of the nextString(), but it would also be useful to provide the
"alphabet" to be used. It would be better as a StringSequence class, though.
{code:title=StringSequence.java}
public class StringSequence
{
public StringSequence(String alphabet, String start);
public String nextString();
}
{code}
> Sequence(String)Utils
> -
>
> Key: LANG-425
> URL: https://issues.apache.org/jira/browse/LANG-425
> Project: Commons Lang
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Robert Scholte
>Priority: Trivial
>
> Don't you think it's kind of strange to have RandomUtils and
> RandomStringUtils, but not just the ordinairy SequenceUtils?
> I've seen commons-id in the sandbox, but maybe some basics should become part
> of commons lang.
> Most classes of within this package are stateless/static, or they have a
> state within a method (such as StrBuilder). SequenceUtils can only be static,
> if it has the startValue.
> For example
> {code}
> SequenceUtils.nextInt(10)
> SequenceUtils.nextString("MORE")
> SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
> SequenceUtils.nextString("C0DE", "0123456789ABCDEF") //next hexadecimal
> {code}
> any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
