[jira] [Commented] (EMAIL-191) MultiPartEmail attach( final DataSource ds, ...) closes the inputstream in data source ds, before reading it.

2023-12-16 Thread Gary D. Gregory (Jira)


[ 
https://issues.apache.org/jira/browse/EMAIL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797499#comment-17797499
 ] 

Gary D. Gregory commented on EMAIL-191:
---

Hello [~Wallenstein61] 

Feel free to provide a reproducible test case or better yet, a PR on GitHub.

> MultiPartEmail attach( final DataSource ds, ...) closes the inputstream in 
> data source ds, before reading it.
> -
>
> Key: EMAIL-191
> URL: https://issues.apache.org/jira/browse/EMAIL-191
> Project: Commons Email
>  Issue Type: Bug
>Affects Versions: 1.5
> Environment: Tested with email-commons 1.5 in tomcat 7.0.x on Windows 
> and Linux.
> The problem is quite straight forward visible in source code 
> {{.org.apache.commons.mail.MultiPartEmail}} line 420 . Therefore I abstain 
> from constructing a self contained example.
>Reporter: Michael Breu
>Priority: Critical
>
> We are creating watermarked pdf's and send them on-the-fly as email 
> attachments. The pdf is created in a separate thread and piped into a 
> PipedInputStream.
> This runs into a Pipe closed IOException, because {{MultiPartEmail attach( 
> final DataSource ds, final String name, final String description)}} closes 
> the inputstream in data source ds, before reading it.
> Comment say's that this is due to windows file locking
> *Expected behavior*: The input stream is read before closing.
>  
> *Workaround*: Buffer the Stream into a ByteArrayInputStream. (This has the 
> disadvantage that we have a high memory load, due to prepared, but not yet 
> sent attachments.
>  
> *Minimum solution*: Document the problem in the java doc.
> *Optimal solution*: It is not really clear to me, what the file locking 
> problem is: Either provide two alternative methods for Files and 
> InputStreams. Or improve the file handling.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Closed] (EMAIL-192) fix errors in javadoc, and add maven-javadoc-plugin to pom.

2023-12-16 Thread Gary D. Gregory (Jira)


 [ 
https://issues.apache.org/jira/browse/EMAIL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed EMAIL-192.
-
Resolution: Resolved

PR closed, closing this ticket.

 

> fix errors in javadoc, and add maven-javadoc-plugin to pom.
> ---
>
> Key: EMAIL-192
> URL: https://issues.apache.org/jira/browse/EMAIL-192
> Project: Commons Email
>  Issue Type: Improvement
>Reporter: Jin Xu
>Priority: Minor
>
> [https://github.com/apache/commons-email/pull/16]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (EMAIL-204) Parsing multipart should not load content in to memory

2023-12-16 Thread Gary D. Gregory (Jira)


 [ 
https://issues.apache.org/jira/browse/EMAIL-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved EMAIL-204.
---
Fix Version/s: 1.6.0
   Resolution: Fixed

Done differently from [PR 135|https://github.com/apache/commons-email/pull/135] 
in git master (see {{InputStreamDataSource}}).

> Parsing multipart should not load content in to memory
> --
>
> Key: EMAIL-204
> URL: https://issues.apache.org/jira/browse/EMAIL-204
> Project: Commons Email
>  Issue Type: Improvement
>Reporter: Deryl Spielman
>Priority: Major
> Fix For: 1.6.0
>
>
> When parsing a MimeMessage and the message has attachments it is eagerly 
> loading the content in to a memory via byteArray to create a DataSource. This 
> is inefficient when all I need is a list of attachments which can be pulled 
> from the content disposition for file name.
> If the attachments are large these lines load it in to memory when perhaps it 
> should keep it as an input stream so as not to force loading in to memory 
> until it's actually used by somewhere else in the code.
> *MimeMessageParser.java*
> {code:java}
>     protected DataSource createDataSource(final Multipart parent, final 
> MimePart part)
>         throws MessagingException, IOException
>     {
>         final DataHandler dataHandler = part.getDataHandler();
>         final DataSource dataSource = dataHandler.getDataSource();
>         final String contentType = 
> getBaseMimeType(dataSource.getContentType());
> >final byte[] content = this.getContent(dataSource.getInputStream());
> >final ByteArrayDataSource result = new ByteArrayDataSource(content, 
> contentType);
>         final String dataSourceName = getDataSourceName(part, dataSource);
>         result.setName(dataSourceName);
>         return result;
>     }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (EMAIL-197) How about a release? :)

2023-12-16 Thread Gary D. Gregory (Jira)


 [ 
https://issues.apache.org/jira/browse/EMAIL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved EMAIL-197.
---
Fix Version/s: 1.6.0
   Resolution: Fixed

A release is forthcoming within a week or two.

> How about a release? :)
> ---
>
> Key: EMAIL-197
> URL: https://issues.apache.org/jira/browse/EMAIL-197
> Project: Commons Email
>  Issue Type: Wish
>Affects Versions: 1.5
>Reporter: Cott Lang
>Priority: Major
> Fix For: 1.6.0
>
>
> It's been what, 4 years since a release?
> We just ran into a bug around accented characters, which was fixed years ago 
> in javax.mail 1.6.0. We're overriding the dependency to fix it, but it 
> appears commons email is already updated, just never released?
>  
> Thanks.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: [PR] EMAIL-204: Disable eager attachment loading on MimeMessageParser [commons-email]

2023-12-16 Thread via GitHub


garydgregory commented on PR #135:
URL: https://github.com/apache/commons-email/pull/135#issuecomment-1858931551

   Hello @HiuKwok,
   
   I am sorry about not getting back to you sooner.
   I belive this functionality is currently implemented, albeit differently, in 
git master. Please verify your use case and close this or update this PR as 
appropriate.
   
   Thank you for your patience!  


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (LANG-1713) ArrayUtils will return null when adding two null arrays, but undocumented

2023-12-16 Thread Gary D. Gregory (Jira)


[ 
https://issues.apache.org/jira/browse/LANG-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797451#comment-17797451
 ] 

Gary D. Gregory commented on LANG-1713:
---

Hello [~john16384] 

I updated the Javadoc to reflect the current behavior.

Feel free to provide a PR on GitHub if you think otherwise, this will let us 
assess the consequences of your proposal when all tests are run. 

> ArrayUtils will return null when adding two null arrays, but undocumented
> -
>
> Key: LANG-1713
> URL: https://issues.apache.org/jira/browse/LANG-1713
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.13.0
>Reporter: John Hendrikx
>Priority: Minor
>  Labels: Null-Safety, null
> Fix For: 3.15.0
>
>
>  
> {color:#00}The code below makes use of `clone`; however `clone` will 
> return `null` when the array is null.{color}
>  
> {color:#00}This means that doing ArrayUtils.addAll(null, null) can return 
> null.  The documentation however makes it appear that this can never happen 
> ("it is always a new array", and "@return The new boolean[] array."){color}
>  
>  
> {color:#3f5fbf}/**{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}Adds all the 
> elements of the given arrays into a new array.{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}The new 
> array contains all of the element of \{@code array1} followed{color}
> {color:#3f5fbf} * by all of the elements \{@code array2}. When an array is 
> returned, it is always{color}
> {color:#3f5fbf} * a new array.{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} * ArrayUtils.addAll(array1, null) = cloned copy of 
> array1{color}
> {color:#3f5fbf} * ArrayUtils.addAll(null, array2) = cloned copy of 
> array2{color}
> {color:#3f5fbf} * ArrayUtils.addAll([], []) = []{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array1 
> the first array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array2 
> the second array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@return{color}{color:#3f5fbf} The new 
> boolean[] array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@since{color}{color:#3f5fbf} 
> 2.1{color}
> {color:#3f5fbf} */{color}
> {color:#80}public{color}{color:#00} 
> {color}{color:#80}static{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}[] 
> {color}{color:#00}addAll{color}{color:#00}({color}{color:#80}final{color}{color:#00}
>  {color}{color:#80}boolean{color}{color:#00}[] 
> {color}{color:#6a3e3e}array1{color}{color:#00}, 
> {color}{color:#80}final{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}... 
> {color}{color:#6a3e3e}array2{color}{color:#00}) {{color}
> {color:#80}if{color}{color:#00} 
> ({color}{color:#6a3e3e}array1{color}{color:#00} == 
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00} 
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00});{color}
> {color:#00} } {color}{color:#80}else{color}{color:#00} 
> {color}{color:#80}if{color}{color:#00} 
> ({color}{color:#6a3e3e}array2{color}{color:#00} == 
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00} 
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00});{color}
> {color:#00} }{color}
> {color:#80}final{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}[] 
> {color}{color:#6a3e3e}joinedArray{color}{color:#00} = 
> {color}{color:#80}new{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}[{color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}
>  + 
> {color}{color:#6a3e3e}array2{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}];{color}
> {color:#00} 
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00},
>  0, {color}{color:#6a3e3e}joinedArray{color}{color:#00}, 0, 
> {color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00});{color}
> {color:#00} 
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00},
>  0, 

[PR] Allow Servlet 4 in OSGi environment. [commons-logging]

2023-12-16 Thread via GitHub


wilx opened a new pull request, #191:
URL: https://github.com/apache/commons-logging/pull/191

   (no comment)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] [LOGGING-189] Fix Import-Package entry for org.slf4j. [commons-logging]

2023-12-16 Thread via GitHub


wilx commented on PR #188:
URL: https://github.com/apache/commons-logging/pull/188#issuecomment-1858780663

   While looking at the imports for the above, I noticed more possible 
problems. Like, the `javax.servlet;version="[2.1.0, 
3.0.0)";resolution:=optional,` import and its constraint. That should be 
`"[2.1.0,5)"` because the 4.0 servlet is compatible with the 2.1.
   
   Is there a log4j2 version 3.x already? Because the constraint here 
`org.apache.logging.log4j;version="[2.0, 4.0)";resolution:=optional,` suggests 
that. It allows >=2 and <4, implying version 3.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] [LOGGING-189] Fix Import-Package entry for org.slf4j. [commons-logging]

2023-12-16 Thread via GitHub


wilx commented on PR #188:
URL: https://github.com/apache/commons-logging/pull/188#issuecomment-1858779746

   You can use a BND library macro like I did there. It results in "[1.7.0,3)" 
which is fine with OSGi.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Reopened] (LANG-1713) ArrayUtils will return null when adding two null arrays, but undocumented

2023-12-16 Thread Sebb (Jira)


 [ 
https://issues.apache.org/jira/browse/LANG-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb reopened LANG-1713:


> ArrayUtils will return null when adding two null arrays, but undocumented
> -
>
> Key: LANG-1713
> URL: https://issues.apache.org/jira/browse/LANG-1713
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.13.0
>Reporter: John Hendrikx
>Priority: Minor
>  Labels: Null-Safety, null
> Fix For: 3.15.0
>
>
>  
> {color:#00}The code below makes use of `clone`; however `clone` will 
> return `null` when the array is null.{color}
>  
> {color:#00}This means that doing ArrayUtils.addAll(null, null) can return 
> null.  The documentation however makes it appear that this can never happen 
> ("it is always a new array", and "@return The new boolean[] array."){color}
>  
>  
> {color:#3f5fbf}/**{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}Adds all the 
> elements of the given arrays into a new array.{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}{color:#3f5fbf}The new 
> array contains all of the element of \{@code array1} followed{color}
> {color:#3f5fbf} * by all of the elements \{@code array2}. When an array is 
> returned, it is always{color}
> {color:#3f5fbf} * a new array.{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} * ArrayUtils.addAll(array1, null) = cloned copy of 
> array1{color}
> {color:#3f5fbf} * ArrayUtils.addAll(null, array2) = cloned copy of 
> array2{color}
> {color:#3f5fbf} * ArrayUtils.addAll([], []) = []{color}
> {color:#3f5fbf} * {color}{color:#7f7f9f}{color}
> {color:#3f5fbf} *{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array1 
> the first array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@param{color}{color:#3f5fbf} array2 
> the second array whose elements are added to the new array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@return{color}{color:#3f5fbf} The new 
> boolean[] array.{color}
> {color:#3f5fbf} * {color}{color:#7f9fbf}@since{color}{color:#3f5fbf} 
> 2.1{color}
> {color:#3f5fbf} */{color}
> {color:#80}public{color}{color:#00} 
> {color}{color:#80}static{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}[] 
> {color}{color:#00}addAll{color}{color:#00}({color}{color:#80}final{color}{color:#00}
>  {color}{color:#80}boolean{color}{color:#00}[] 
> {color}{color:#6a3e3e}array1{color}{color:#00}, 
> {color}{color:#80}final{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}... 
> {color}{color:#6a3e3e}array2{color}{color:#00}) {{color}
> {color:#80}if{color}{color:#00} 
> ({color}{color:#6a3e3e}array1{color}{color:#00} == 
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00} 
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00});{color}
> {color:#00} } {color}{color:#80}else{color}{color:#00} 
> {color}{color:#80}if{color}{color:#00} 
> ({color}{color:#6a3e3e}array2{color}{color:#00} == 
> {color}{color:#80}null{color}{color:#00}) {{color}
> {color:#7f0055}return{color}{color:#00} 
> {color}{color:#00}clone{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00});{color}
> {color:#00} }{color}
> {color:#80}final{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}[] 
> {color}{color:#6a3e3e}joinedArray{color}{color:#00} = 
> {color}{color:#80}new{color}{color:#00} 
> {color}{color:#80}boolean{color}{color:#00}[{color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}
>  + 
> {color}{color:#6a3e3e}array2{color}{color:#00}.{color}{color:#c0}length{color}{color:#00}];{color}
> {color:#00} 
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array1{color}{color:#00},
>  0, {color}{color:#6a3e3e}joinedArray{color}{color:#00}, 0, 
> {color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00});{color}
> {color:#00} 
> System.{color}{color:#00}arraycopy{color}{color:#00}({color}{color:#6a3e3e}array2{color}{color:#00},
>  0, {color}{color:#6a3e3e}joinedArray{color}{color:#00}, 
> {color}{color:#6a3e3e}array1{color}{color:#00}.{color}{color:#c0}length{color}{color:#00},
>  
> {color}{color:#6a3e3e}array2{color}{color:#00}.{color}{color:#c0}length{color}{color:#00});{color}
> {color:#7f0055}return{color}{color:#00}