[jira] Commented: (FILEUPLOAD-59) [fileupload] Memory Issue
[ https://issues.apache.org/jira/browse/FILEUPLOAD-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508738 ] Jochen Wiedmann commented on FILEUPLOAD-59: --- Apart from possible changes, a streaming API was added in 1.2. If you are sensitive for memory considerations, this is the way to go anyways. [fileupload] Memory Issue - Key: FILEUPLOAD-59 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-59 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Vimil Saju The reason for out of memory exception is that a FileItem object is created for each request parameter whether it is file or an ordinary string parameter. the FileItem object has a field of type DeferredFileStream which is initialized to 262144 bytes (256 Kb) so if there are around 1000 request parameters, around 256 MB of space will be required to hold the request parameters even though most parameters may require only 8 to 10 bytes of memory for storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-59) [fileupload] Memory Issue
[ https://issues.apache.org/jira/browse/FILEUPLOAD-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508743 ] Felix K F Chan commented on FILEUPLOAD-59: -- Since I am using Struts v1.1, when even there is multipart/form-data request, it use fileupload v1.0. I am not sure if I put fileupload v1.2 together with Struts v1.1, will they work. I notice the code in fileupload v1.2 has changed FileUploadBase to use streaming, but will it save some memory for form fields in the case mentioned in this issue? [fileupload] Memory Issue - Key: FILEUPLOAD-59 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-59 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Vimil Saju The reason for out of memory exception is that a FileItem object is created for each request parameter whether it is file or an ordinary string parameter. the FileItem object has a field of type DeferredFileStream which is initialized to 262144 bytes (256 Kb) so if there are around 1000 request parameters, around 256 MB of space will be required to hold the request parameters even though most parameters may require only 8 to 10 bytes of memory for storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-59) [fileupload] Memory Issue
[ https://issues.apache.org/jira/browse/FILEUPLOAD-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508745 ] Jochen Wiedmann commented on FILEUPLOAD-59: --- I see absolutely no reason, why we should still support 1.1. This applies, in particular, to memory considerations and stuff like that. The streaming API was invented exactly for that purpose. [fileupload] Memory Issue - Key: FILEUPLOAD-59 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-59 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Vimil Saju The reason for out of memory exception is that a FileItem object is created for each request parameter whether it is file or an ordinary string parameter. the FileItem object has a field of type DeferredFileStream which is initialized to 262144 bytes (256 Kb) so if there are around 1000 request parameters, around 256 MB of space will be required to hold the request parameters even though most parameters may require only 8 to 10 bytes of memory for storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-59) [fileupload] Memory Issue
[ https://issues.apache.org/jira/browse/FILEUPLOAD-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508755 ] Felix K F Chan commented on FILEUPLOAD-59: -- It looks like that fileupload v1.2 plus io v1.31 should solve the problem. [fileupload] Memory Issue - Key: FILEUPLOAD-59 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-59 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.0 Final Environment: Operating System: All Platform: All Reporter: Vimil Saju The reason for out of memory exception is that a FileItem object is created for each request parameter whether it is file or an ordinary string parameter. the FileItem object has a field of type DeferredFileStream which is initialized to 262144 bytes (256 Kb) so if there are around 1000 request parameters, around 256 MB of space will be required to hold the request parameters even though most parameters may require only 8 to 10 bytes of memory for storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-138) Fail to upload small files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508762 ] Martin Gröger commented on FILEUPLOAD-138: -- Yes, with the current snapshot the problem disappears. I took also a current shanpshot from commons-io (otherwise it doesn't compile). The question for me was: How to know which version of commons-io is the related one ?! Fail to upload small files -- Key: FILEUPLOAD-138 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-138 Project: Commons FileUpload Issue Type: Bug Environment: Tomcat 5.5 on Suse Linux 10.0 Reporter: Martin Gröger Priority: Critical Upload for very small files failed. The size (of failing) is lass than 58/59 bytes. It depends on the exact size of the keepRegion variable of the MultipartStream. Files less than this size contain no data at the target. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
Agree with Niall.. Archives are pretty much unusable with commits messages and jira issues.. Mvgr, Martin Niall Pemberton wrote: On 6/27/07, Torsten Curdt [EMAIL PROTECTED] wrote: snip #=== [1] Mailing List (i) addresses I. [EMAIL PROTECTED] * Henri Yandell[EMAIL PROTECTED] * Jochen Wiedmann [EMAIL PROTECTED] * Mario Ivankovits [EMAIL PROTECTED] * Stephen Colebourne [EMAIL PROTECTED] * Dennis Lundberg [EMAIL PROTECTED] * Niall Pemberton [EMAIL PROTECTED] * Martin van den Bemt [EMAIL PROTECTED] * Oliver Zeigermann[EMAIL PROTECTED] * Jörg Schaible[EMAIL PROTECTED] * Oliver Heger [EMAIL PROTECTED] * Matt Benson [EMAIL PROTECTED] * Martin Cooper[EMAIL PROTECTED] * Phil Steitz [EMAIL PROTECTED] * Torsten Curdt[EMAIL PROTECTED] * Daniel Savarese [EMAIL PROTECTED] * Rory Winston [EMAIL PROTECTED] * Luc Maisonobe[EMAIL PROTECTED] * Joerg Pietschmann[EMAIL PROTECTED] * Dion Gillard [EMAIL PROTECTED] * Brent Worden [EMAIL PROTECTED] * Simon Kitching [EMAIL PROTECTED] * Rahul Akolkar[EMAIL PROTECTED] II. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] III. [EMAIL PROTECTED] migrate subscribers from commons- [EMAIL PROTECTED] NOTE: if possible forward [EMAIL PROTECTED] to [EMAIL PROTECTED] My preference is commits@ is not forwarded to dev - makes searching mail archives easier - also in discussion on splitting the lists in the past we've talked about having an issues@ list as well. Not sure what the consensus was, but thats my preference. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
I don't see a problem in doing the last 2 years, which kind of gives us a nice clean committer base and if we miss people, they simply need to ask for it. Another options is just copy pasting the jakarta committers block from asf-authorization, that way you know everyone who has access, still has access.. Mvgr, Martin Henri Yandell wrote: On 6/27/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/28/07, Henri Yandell [EMAIL PROTECTED] wrote: On 6/27/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 6/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/27/07, Henri Yandell [EMAIL PROTECTED] wrote: Personally, my vote would be to say: commons=committers You mean all apache committers? I agree that we should continue the tradition of granting commons karma to any committer who asks for it. I don't know much about how this works in svn or what the risk / downside of auto-granting commons karma to new committers would be, but I agree with the principle that any ASF committer should be welcome here. There are also a lot of current commons committers missing from the list above. My preference would be to have them remain commons committers if that is not too hard to do. In any case, any current commons committer who wants karma should get it. I agree - please lets not remove commit privledge from anyone who currently has it in Commons. Presuming no one recognizes the social genius of my first proposal, then I recommend that we make the list of committers be anyone who has committed in the last 2 years. Why have you gone from proposing to add any remaining ASF Commiters that don't currently have access to now removing access from anyone who hasn't committed in the last two years? This seems a bit random in principle to me to take one position to open things up one minute and then another to make it more restrictive the next. Just looking for something simple. I also dislike arbitrary limits - you choose 2 years - maybe someone else will prefer 1 year and so on. I still think anyone that currently has access should keep it and not loose their commit access to Commons. Pondered that one. We could keep the commons commit list as the jakarta group. Seemed a bit odd though. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (FILEUPLOAD-138) Fail to upload small files
[ https://issues.apache.org/jira/browse/FILEUPLOAD-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved FILEUPLOAD-138. Resolution: Duplicate Fix Version/s: 1.2.1 Assignee: Jochen Wiedmann The question for the required version of commons-io is answered by the POM file, which is distributed together with the jar file. Fail to upload small files -- Key: FILEUPLOAD-138 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-138 Project: Commons FileUpload Issue Type: Bug Environment: Tomcat 5.5 on Suse Linux 10.0 Reporter: Martin Gröger Assignee: Jochen Wiedmann Priority: Critical Fix For: 1.2.1 Upload for very small files failed. The size (of failing) is lass than 58/59 bytes. It depends on the exact size of the keepRegion variable of the MultipartStream. Files less than this size contain no data at the target. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[nightly build] lang failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070628/lang.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508808 ] Dennis Kieselhorst commented on CONFIGURATION-282: -- Unfortunately I cannot add a testcase yet, because the error only occurs in production environment. I will try to reproduce it. I think this is the corresponding line: http://jakarta.apache.org/commons/configuration/xref/org/apache/commons/configuration/HierarchicalConfiguration.html#721 NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
I also would strongly prefer to use this opportunity to create a commits list and an issues list. Commons is big enough to need it, and it would increase the signal to noise on the main list, especially when searching. Stephen - Original Message From: Martin van den Bemt [EMAIL PROTECTED] Agree with Niall.. Archives are pretty much unusable with commits messages and jira issues.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JCI-50) Javac 1.5 source and target parameters
Javac 1.5 source and target parameters -- Key: JCI-50 URL: https://issues.apache.org/jira/browse/JCI-50 Project: Commons JCI Issue Type: Bug Components: compiler eclipse, compiler javac Affects Versions: 1.0 Reporter: Olexandr Zakordonskyy Priority: Blocker Unable to set source and target version to 1.5. For javac its -source and -target arguments. Same for jci-eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MATH-167) ConvergenceException in normal CDF
ConvergenceException in normal CDF -- Key: MATH-167 URL: https://issues.apache.org/jira/browse/MATH-167 Project: Commons Math Issue Type: Bug Reporter: Mikko Kauppila Priority: Minor NormalDistributionImpl::cumulativeProbability(double x) throws ConvergenceException if x deviates too much from the mean. For example, when x=+/-100, mean=0, sd=1. Of course the value of the CDF is hard to evaluate in these cases, but effectively it should be either zero or one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508854 ] Niall Pemberton commented on LANG-326: -- Its been a while since I posted this - in the absence of anyone stepping with alternatives [CaseInsensitiveStringUtils / Collators] I plan to commit this unless someone objects StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (NET-162) Logout failure
Logout failure -- Key: NET-162 URL: https://issues.apache.org/jira/browse/NET-162 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Windows Reporter: Arash Joorabchi Hi all, I have a small class that just logs into a FTP serever and then Logs out I tried both of the following lines for logging out 1. ftp.logout(); 2. ftp.sendCommand(quit); and they both cause this exception: Connected to www.ideas.ie. 220 ProFTPD 1.3.0a Server (IDEAs FTP Server) [193.1.99.22] 230 User logged in. java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) 0 at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:619) Any suggestions ? Does ftp.disconnect has the same effect as logging out ? Because disconnect function works allright. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: infrastructure work for TLP move
+1. On 6/28/07, Stephen Colebourne [EMAIL PROTECTED] wrote: I also would strongly prefer to use this opportunity to create a commits list and an issues list. Commons is big enough to need it, and it would increase the signal to noise on the main list, especially when searching. Stephen - Original Message From: Martin van den Bemt [EMAIL PROTECTED] Agree with Niall.. Archives are pretty much unusable with commits messages and jira issues.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.NoSuchMethodError: com.sun.activation.registries.MailcapFile.getMailcapList(Ljava/lang/String;)Ljava/util/Map;
On Tue, 2007-06-26 at 13:17 -0400, Shah, Dhara (CT) wrote: Hey, I have used the SimpleMail class just as it is on the User Guide. However, I keep getting an error java.lang.NoSuchMethodError: com.sun.activation.registries.MailcapFile.getMailcapList(Ljava/lang/Stri ng;)Ljava/util/Map; Can someone help me? I would guess that you have the wrong version of the activation jar in your classpath. Check the requirements for commons-email: http://jakarta.apache.org/commons/email/dependencies.html Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons PMC += Rahul Akolar
ACK'd. On 6/26/07, Torsten Curdt [EMAIL PROTECTED] wrote: Please acknowledge http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/ 200706.mbox/% [EMAIL PROTECTED] cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons PMC += Simon Kitching
ACK'd. On 6/26/07, Torsten Curdt [EMAIL PROTECTED] wrote: Please acknowledge http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/ 200706.mbox/% [EMAIL PROTECTED] cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508919 ] Oliver Heger commented on CONFIGURATION-282: A NPE on this line would mean that getExpressionEngine() returns null, which normally should not happen. Is it possible that you do something with serialization or hot-deployment of your application? This could be an explanation why the static defaultExpressionEngine field is null. NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508943 ] Stephen Kestle commented on LANG-326: - I'm fine with it - at a later point these methods could be re-plumbed to use collators, and other methods added (I'll probably do it when I actually start using collators for real). As a side question, how much do we care about speed and [premature?] optimization? if I were to upgrade and overload these methods, would it be a problem to create Collator objects for the existing defaults and use a modified algorithm to do the evaluation? I'd presume the str.regionMatches() would be faster by a few picos, but I prefer brevity, as well as indication of the correct (international) way. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-326) StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods
[ https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508954 ] Niall Pemberton commented on LANG-326: -- I implemented these methods using str.regionMatches() with brevity and correctness in mind and not optimization. Looking at other existing case insensitive String comparrison implementations in StringUtils - they achieved brevity by using str.toUpperCase() and then calling the case sensitive flavour of the method. IMO these are not quite correct since the case insensitive functionality provided by the String class (which IMO StringUtils should be compatible with) do more than that (with a comment that upper case comparison has issues with the Georgian alphabet). Using regionMatches() allowed the same code to be (re-)used for both the case sensitive and insensitive implementations and for them to be compatible with the case insensitive functionality provided by String. So optimization was just a nice by-product. On your Collator implementation IMO it would be better as a new utility class for those that need that functionality (I18NStringUtils?) - which would give people a choice and ties in nicely with what java provides - i.e. a choice of 2 different mechanisms. StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase / removeStartIgnoreCase / removeEndIgnoreCase methods Key: LANG-326 URL: https://issues.apache.org/jira/browse/LANG-326 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-326-Start-End-With-2.patch I'd like the following new start/end methods for StringUtils: startsWith - handles nulls endsWith - handles nulls startsWithIgnoreCase - handles nulls, case insensitive endsWithIgnoreCase - handles nulls, case insensitive removeStartIgnoreCase - handles nulls, case insensitive removeEndIgnoreCase - handles nulls, case insensitive -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
