[jira] Created: (IO-137) Added method for getting InputStream from ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation and copy
Added method for getting InputStream from ByteArrayOutputStream & IOUtils avoiding unnecessary array allocation and copy Key: IO-137 URL: https://issues.apache.org/jira/browse/IO-137 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Affects Versions: 1.3.2, 1.4, AFTER-1.4 Environment: Any OS with appropriate JVM Reporter: Nikunj Trivedi Patch inclues following two methods and test cases for both. 1) New Method: ByteArrayOutputStream.toInputStream ByteArrayOutputStream exposes its byte buffers by toByteArray(), which creates a fresh buffer and copy existing data to it. A new method toInputStream() available in patch returns the current contents of baos, as an InputStream, avoiding unnecessary allocation and copying. 2) New Method: IOUtils.toFullyBufferedInputStream There are situations where the InputStream source is available and it has to be passed to different modules for processing. It is needed to fetch the full contents of the InputStream in internal buffer(IOUtils.toByteArray() ), convert this buffer to ByteArrayInputStream and use that stream instead. But this is wasteful since toByteArray() requires one fresh allocation and copy operation. New method copies InputStream to ByteArrayOutputStream and returns baos.toInputStream(), avoiding unnecessary memory allocation and copy. Testcases are available in respective classes. -- 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#action_12544133 ] Bjorn Townsend commented on EMAIL-69: - I'll see what I can do. Hope vacation's going well. :) > 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 > > 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.
[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#action_12544120 ] Ben Speakmon commented on EMAIL-69: --- I'm on vacation this week, so I can't get to this before the beginning of December. Could someone supply a patch and unit test? That would make it go quite a bit faster. > 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 > > 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.
[jira] Updated: (VALIDATOR-251) url with brackets is not validated thru URLvalidator class.
[
https://issues.apache.org/jira/browse/VALIDATOR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Meenal Gupta updated VALIDATOR-251:
---
Component/s: Routines
Priority: Major (was: Critical)
Description:
Please let me know when VALIDATOR-218, Committed revision 590915 is gng on
release.
As the Below issue is already solved in the bug is VALIDATOR-218.
I cannot find this bus fix in Relaese not for the latest version of commons
jar.
This is very critical for the my application currrent release.
URLvalidator isValid() returns false for validation of urls's which have
brackets "(" , ")" as one of the content.
url with brackets in them are valid urls , as brackets () are part of the
unreserved characters.
We are using the URLValidator isValid() method to validate Urls.
if (urlValidator.isValid(url)) {
return true;
}
But one of the url is with brackets are rejected by this method.
i am using 1.3.1 version.
Is there something in latest version which already have have fix to this bug.
or my understanding is not correct
Please clarify.
was:
URLvalidator isValid() returns false for validation of urls's which have
brackets "(" , ")" as one of the content.
url with brackets in them are valid urls , as brackets () are part of the
unreserved characters.
We are using the URLValidator isValid() method to validate Urls.
if (urlValidator.isValid(url)) {
return true;
}
But one of the url is with brackets are rejected by this method.
i am using 1.3.1 version.
Is there something in latest version which already have have fix to this bug.
or my understanding is not correct
Please clarify.
Issue Type: Wish (was: Bug)
Environment: Java 1.4
> url with brackets is not validated thru URLvalidator class.
> ---
>
> Key: VALIDATOR-251
> URL: https://issues.apache.org/jira/browse/VALIDATOR-251
> Project: Commons Validator
> Issue Type: Wish
> Components: Routines
>Affects Versions: 1.3.1 Release
> Environment: Java 1.4
>Reporter: Meenal Gupta
> Fix For: 1.3.1 Release
>
>
> Please let me know when VALIDATOR-218, Committed revision 590915 is gng on
> release.
> As the Below issue is already solved in the bug is VALIDATOR-218.
> I cannot find this bus fix in Relaese not for the latest version of commons
> jar.
> This is very critical for the my application currrent release.
> URLvalidator isValid() returns false for validation of urls's which have
> brackets "(" , ")" as one of the content.
> url with brackets in them are valid urls , as brackets () are part of the
> unreserved characters.
> We are using the URLValidator isValid() method to validate Urls.
> if (urlValidator.isValid(url)) {
> return true;
> }
> But one of the url is with brackets are rejected by this method.
> i am using 1.3.1 version.
> Is there something in latest version which already have have fix to this bug.
> or my understanding is not correct
> Please clarify.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-136) HexDump's use of static StringBuffers isn't thread-safe
[ https://issues.apache.org/jira/browse/IO-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-136. Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=rev&revision=596642 > HexDump's use of static StringBuffers isn't thread-safe > --- > > Key: IO-136 > URL: https://issues.apache.org/jira/browse/IO-136 > Project: Commons IO > Issue Type: Bug >Affects Versions: 1.3.2 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > > HexDump has two private static dump() method's that alter static instances of > StringBuffer: > dump(long) modifies static StringBuffer variable _lbuffer returning _lbuffer > dump(char) modifies static StringBuffer variable _cbuffer returning _cbuffer > Both these methods are called by the public static dump(byte[], long, > OutputStream, int) method. Multiple threads calling the public dump method at > the same time could cause these StringBuffer to contain mixed up data and > result in a bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-136) HexDump's use of static StringBuffers isn't thread-safe
HexDump's use of static StringBuffers isn't thread-safe --- Key: IO-136 URL: https://issues.apache.org/jira/browse/IO-136 Project: Commons IO Issue Type: Bug Affects Versions: 1.3.2 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 1.4 HexDump has two private static dump() method's that alter static instances of StringBuffer: dump(long) modifies static StringBuffer variable _lbuffer returning _lbuffer dump(char) modifies static StringBuffer variable _cbuffer returning _cbuffer Both these methods are called by the public static dump(byte[], long, OutputStream, int) method. Multiple threads calling the public dump method at the same time could cause these StringBuffer to contain mixed up data and result in a bug. -- 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#action_12543845
]
Tobias Bocanegra commented on EMAIL-69:
---
i guess the problem was introduced in issue [EMAIL-50].
suggest to use the "alternative" container not only if there are embedded
images but also if both a html and text message are set, eg:
boolean useAlternative = this.inlineEmbeds.size() > 0
|| (EmailUtils.isNotEmpty(this.html) &&
EmailUtils.isNotEmpty(this.text));
and then later:
msgText = new MimeBodyPart();
if (useAlternative)
{
subContainer.addBodyPart(msgText);
}
else
{
container.addBodyPart(msgText);
}
> 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
>
> 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.
