[jira] Commented: (IO-71) [io] PipedUtils
[ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568479#action_12568479 ] Jukka Zitting commented on IO-71: - You're right, my solution suffers from having an unlimited buffer. Personally I don't think that's too much of an issue (all the really troublesome examples I can come up with are highly hypothetical), but I you're right that a thread-based solution is more robust. Too bad Java doesn't do continuations... However, my point still stands that your underlying problem isn't about converting an OutputStream to an InputStream, but about using an OutputStream filter on an InputStream. Using a pipe is good a way to do it, but for example the propagation of exceptions is only relevant for filtering, not piping. This is why I think that none of the OutputStream objects and other pipe constructs should really be visible to the user, and that using "filter" in naming is more appropriate than "pipe". > [io] PipedUtils > --- > > Key: IO-71 > URL: https://issues.apache.org/jira/browse/IO-71 > Project: Commons IO > Issue Type: Improvement > Components: Utilities > Environment: Operating System: All > Platform: All >Reporter: David Smiley >Priority: Minor > Fix For: 2.x > > Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch > > > I developed some nifty code that takes an OutputStream and sort of reverses > it as if it were an > InputStream. Error passing and handling close is dealt with. It needs > another thread to do the work > which runs in parallel. It uses Piped streams. I created this because I > had to conform > GZIPOutputStream to my framework which demanded an InputStream. > See URL to source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-408) StringUtils.isLength(String string, int length) : boolean
[ https://issues.apache.org/jira/browse/LANG-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568554#action_12568554 ] Jörg Gottschling commented on LANG-408: --- Yes, that's OK. > StringUtils.isLength(String string, int length) : boolean > - > > Key: LANG-408 > URL: https://issues.apache.org/jira/browse/LANG-408 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Jörg Gottschling >Priority: Minor > > Just a null safe way to check the length of an String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-71) [io] PipedUtils
[ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568559#action_12568559 ] David Smiley commented on IO-71: I agree with what you're saying. But as far as it being "not too much of an issue"... I wonder if the risk isn't so much "normal expected data" but instead a security concern resulting in a denial of service. Lets say hypothetically that we had some decompressing outputstream. So if the input size is X, then the output would generally be larger than X (and hence the requirements of our buffer). In normal data the ratio might be a ratio of say 1:10 and since your code requests data in 1KB chunks, it'd need a 10KB buffer. But an attacker might give this system data that has an extreme compression ratio of say 1:1000 (lots of zeroes, whatever). Like say a 100MB file consisting of all one's which would compress like mad. A system based on this code would then consume all available memory and more or less crash. The size of the input file needed to cause this to occur depends on both the deployed environment and the compression ratio achievable. I admit I'm sort of a perfectionist so I may be making a bigger deal out of this than is warranted. If you really do insist on a variation of your solution, I recommend you have internal warning thresholds which cause warnings to be logged beyond certain thresholds to alert people of a potential problem. > [io] PipedUtils > --- > > Key: IO-71 > URL: https://issues.apache.org/jira/browse/IO-71 > Project: Commons IO > Issue Type: Improvement > Components: Utilities > Environment: Operating System: All > Platform: All >Reporter: David Smiley >Priority: Minor > Fix For: 2.x > > Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch > > > I developed some nifty code that takes an OutputStream and sort of reverses > it as if it were an > InputStream. Error passing and handling close is dealt with. It needs > another thread to do the work > which runs in parallel. It uses Piped streams. I created this because I > had to conform > GZIPOutputStream to my framework which demanded an InputStream. > See URL to source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COLLECTIONS-285) TreeBidiMap should implement Serializable
TreeBidiMap should implement Serializable - Key: COLLECTIONS-285 URL: https://issues.apache.org/jira/browse/COLLECTIONS-285 Project: Commons Collections Issue Type: Improvement Components: BidiMap Affects Versions: 3.2 Reporter: Geert Pante TreeBidiMap does not implement Serializable. DualTreeBidiMap does. It's just a matter of checking which fields should be transient and done. In fact, all Maps should be Serializable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-405) StringUtils.truncate() to cut out middle part of a String
[ https://issues.apache.org/jira/browse/LANG-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568703#action_12568703 ] Gregor B. Rosenauer commented on LANG-405: -- actually public String truncateMiddle(String str, int length); would suffice since the middle part is shortened to an ellipsis "...", or was the "String middle" ment as a placeholder? Anyway, 'nough talking, I see your hint clearly:) Hope to have some time by the end of the week to look into this. > StringUtils.truncate() to cut out middle part of a String > - > > Key: LANG-405 > URL: https://issues.apache.org/jira/browse/LANG-405 > Project: Commons Lang > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Gregor B. Rosenauer >Priority: Minor > Fix For: 3.0 > > > It would be handy to have a String method that cuts out the middle part of a > String such that as much as possible is kept from the start and end of the > String, but the middle part is replaced by an ellipsis "..." > BeOS had a function like this, but it's poorly documented, missing examples: > http://www.beunited.org/bebook/The%20Support%20Kit/String.html#Truncate() > e.g.: > A very long text with unimportant stuff in the middle but interesting start > and end to see if the text is complete. > becomes: > A very long text...to see if the text is complete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-410) Ambiguous / confusing names in StringUtils replace* methods
[ https://issues.apache.org/jira/browse/LANG-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568708#action_12568708 ] Sebb commented on LANG-410: --- commit -m "LANG-410 - Ambiguous / confusing names in StringUtils replace* methods" src/java/org/apache/commons/lang/StringUtils.java Committed revision 627588. > Ambiguous / confusing names in StringUtils replace* methods > --- > > Key: LANG-410 > URL: https://issues.apache.org/jira/browse/LANG-410 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Fix For: 2.4 > > Attachments: StringUtils.patch > > > The recently added replaceEach* methods use "repl" for the original string > list, and "with" for the new (replacement) string list. > These names are rather confusing. > RE engines tend to use words such as: > Perl: > searchlist > replacementlist > ORO: > pattern > replacement > Java has String.replace(regex, replacement) > In all cases, "replacement" is used for the NEW string, not the original > string which is to be replaced. > Seems to me that searchString/List and replacement[List] would be unambiguous > as well as descriptive. > Also useful in IDEs which show possible method completions. > Changing the names of the parameters would not affect the API. > Patch to follow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EMAIL-69) HtmlEmail generated email don't display in Macos X Mail.app
[ https://issues.apache.org/jira/browse/EMAIL-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568820#action_12568820 ] Ben Speakmon commented on EMAIL-69: --- Bjorn, can you throw a fix in for this? > HtmlEmail generated email don't display in Macos X Mail.app > --- > > Key: EMAIL-69 > URL: https://issues.apache.org/jira/browse/EMAIL-69 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.1 > Environment: Macos X 10.4 with Mail.app >Reporter: Numa Schmeder > Attachments: EMAIL-69-fix.patch, EMAIL-69-test.patch > > > Hi, > The mail generated by HtmlEmail seems boggus in its mime layout. Mail.app > doesn't recognize and display the html part when you send a mail with a Html > and Text part as alternative. > For example this email will only display the text part and not the html part > on Mail.app: > HtmlEmail htmlEmail = new HtmlEmail(); > htmlEmail.setHtmlMsg(htmlMessage); > htmlEmail.setTextMsg(textMessage); > email.setFrom(from,fromName); > email.addTo(to, toName); > email.setSubject(subject); > email.send(); > > But this email will disply correctly the html in Mail.app: > HtmlEmail htmlEmail = new HtmlEmail(); > htmlEmail.setHtmlMsg(htmlMessage); > email.setFrom(from,fromName); > email.addTo(to, toName); > email.setSubject(subject); > email.send(); > The bug might be I think in the mime layout, I looked at the raw email > source and the mime layout is as follow: > MIME-Version: 1.0 > Content-Type: multipart/related; > boundary="=_Part_0_11727281.1194085710604" > --=_Part_0_11727281.1194085710604 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > Ch=C3=A8re Mme Dupont ,=20 > Text Blah blah > --=_Part_0_11727281.1194085710604 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > http://www.= > w3.org/TR/html4/loose.dtd"> > > > > = > =20 > =09 My Email > > > > Ch=C3=A8re Mme Dupont ,=20 > > Blah Blah html content > > > --=_Part_0_11727281.1194085710604-- > This is wrong, I am not an expert but shouldn't it be multipart/alternative ? > In all other html email I have checked the mime layout uses > multipart/alternative. > I hop there is a quick fix for this. > Thank you for your help. > Numa -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
