[jira] [Reopened] (EMAIL-138) Czech/Slovak diacritic marks in the file name of the attached file screw whole sent email
[ https://issues.apache.org/jira/browse/EMAIL-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened EMAIL-138: AFAICT, the filename should not be encoded by Commons Email. See the Javadoc for MimeBodyPart#setFileName(String) [1] Commons Email is a wrapper for JavaMail, so it should not be doing its own encoding. Encoding should be left to JavaMail. I think this 'fix' needs to be reverted. However the Commons Javadoc should be updated to point to [1] [1] https://javamail.java.net/nonav/docs/api/javax/mail/internet/MimeBodyPart.html#setFileName-java.lang.String- > Czech/Slovak diacritic marks in the file name of the attached file screw > whole sent email > - > > Key: EMAIL-138 > URL: https://issues.apache.org/jira/browse/EMAIL-138 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.3.2 > Environment: Windows 7, JDK 7 (6 compatible). >Reporter: qed >Priority: Minor > Labels: diacritic > Fix For: 1.3.3 > > > Czech/Slovak diacritic marks in the file name of the attached file screw > whole sent email. Email will arrive but it's content will be messy. An > example of a filename which does this is "nazevřšččššě.txt". Optionally put > some text in email and in file. I tried HtmlEmail. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (EMAIL-138) Czech/Slovak diacritic marks in the file name of the attached file screw whole sent email
[ https://issues.apache.org/jira/browse/EMAIL-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933898#comment-15933898 ] Sebb commented on EMAIL-138: Associated commit: URL: http://svn.apache.org/r1592866 Log: [EMAIL-138] Filenames of attachments were not properly encoded. Thanks to qed. Added: commons/proper/email/trunk/src/test/resources/eml/html-attachment-encoded-filename.eml Modified: commons/proper/email/trunk/src/changes/changes.xml commons/proper/email/trunk/src/main/java/org/apache/commons/mail/MultiPartEmail.java commons/proper/email/trunk/src/test/java/org/apache/commons/mail/SendWithAttachmentsTest.java commons/proper/email/trunk/src/test/java/org/apache/commons/mail/util/MimeMessageParserTest.java > Czech/Slovak diacritic marks in the file name of the attached file screw > whole sent email > - > > Key: EMAIL-138 > URL: https://issues.apache.org/jira/browse/EMAIL-138 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.3.2 > Environment: Windows 7, JDK 7 (6 compatible). >Reporter: qed >Priority: Minor > Labels: diacritic > Fix For: 1.3.3 > > > Czech/Slovak diacritic marks in the file name of the attached file screw > whole sent email. Email will arrive but it's content will be messy. An > example of a filename which does this is "nazevřšččššě.txt". Optionally put > some text in email and in file. I tried HtmlEmail. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933649#comment-15933649 ] Sebb commented on COLLECTIONS-601: -- Does not fail on Jenkins: https://builds.apache.org/view/Apache%20Commons/job/Commons-Collections-Java8/1/console The error looks like it may be an ordering issue. Could be due to a test bug, a code bug or a JVM bug. > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NET-584) Error when using org.apache.commons.net.ftp.FTPClient setControlKeepAliveTimeout
[
https://issues.apache.org/jira/browse/NET-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-584.
--
Resolution: Fixed
Fix Version/s: 3.7
Thanks for confirming the fix has worked and the help in testing the issue.
URL: http://svn.apache.org/viewvc?rev=1787849=rev
Log:
NET-584 Error when using org.apache.commons.net.ftp.FTPClient
setControlKeepAliveTimeout
Modified:
commons/proper/net/trunk/src/changes/changes.xml
commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPClient.java
> Error when using org.apache.commons.net.ftp.FTPClient
> setControlKeepAliveTimeout
>
>
> Key: NET-584
> URL: https://issues.apache.org/jira/browse/NET-584
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Reporter: Kazantsev Andrey Sergeevich
> Fix For: 3.7
>
>
> I have a question about using library commons-net-3.4.jar
> Question is about org.apache.commons.net.ftp.FTPClient method
> setControlKeepAliveTimeout.
> Read about using it on:
> https://commons.apache.org/proper/commons-net/apidocs/org/apache/commons/net/ftp/FTPClient.html
> When I use it in my code I get this error:
> {code}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:163)
> at java.net.SocketInputStream.read(SocketInputStream.java:133)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:322)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:364)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:210)
> at java.io.InputStreamReader.read(InputStreamReader.java:205)
> at java.io.BufferedReader.fill(BufferedReader.java:165)
> at java.io.BufferedReader.read(BufferedReader.java:186)
> at
> org.apache.commons.net.io.CRLFLineReader.readLine(CRLFLineReader.java:58)
> at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:313)
> at org.apache.commons.net.ftp.FTP.__getReplyNoReport(FTP.java:303)
> at org.apache.commons.net.ftp.FTPClient$CSL.cleanUp(FTPClient.java:3838)
> at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:695)
> at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:643)
> at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:2033)
> at ru.mdm.File.Transfer.FTP.PutRemoteFileBinary(FTP.java:192)
> at
> ru.mdm.File.Transfer.TimeLimit.Thread.Protocol.PutRemoteFileBinaryThread.actionsToExecute(PutRemoteFileBinaryThread.java:23)
> at
> ru.mdm.File.Transfer.TimeLimit.OperationThread.run(OperationThread.java:60)
> {code}
> Without enabling this option all works fine.
> Here is the code:
> {code}
> package ru.mdm.File.Transfer;
> import bin.ru.osa.common.utils.*;
> import java.util.List;
> import java.io.*;
> import com.ibm.broker.javacompute.MbJavaComputeNode;
> import com.ibm.broker.plugin.*;
> import org.apache.commons.net.ftp.*;
> import org.apache.commons.net.*;
> import ru.mdm.File.Transfer.Options.OptionsXMLProcessor;
> public class FTP implements Protocol
> {
>
> FTPClient client = new FTPClient();
>
> OptionsXMLProcessor optionsXMLProcessor;
>
>
> boolean st;
> String LastMessage = new String();
>
> boolean ignoreErrors = false;
>
>
> public FTP()
> {
> super();
> }
>
> protected void finalize() { disconnect(); }
>
> public void connect(String CntName,
> String Host,
> String Port,
> String L,
> String P) throws Exception
> {
> try
> {
> client.setControlKeepAliveTimeout(300);
> client.connect(Host);
> client.login(L, P);
> CheckState();
> }
> catch(Exception e)
> {
>LastMessage=client.getReplyString();
>if(LastMessage == null) LastMessage = e.getMessage();
>
>e.printStackTrace();
>
>throw e;
> }
> }
>
> public void disconnect()
> {
> try
> {
> if(client.isConnected())
> {
> client.logout();
> client.disconnect();
> }
> }
> catch(Exception e)
> {
>
[jira] [Updated] (NET-584) Error when using org.apache.commons.net.ftp.FTPClient setControlKeepAliveTimeout
[
https://issues.apache.org/jira/browse/NET-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-584:
-
Summary: Error when using org.apache.commons.net.ftp.FTPClient
setControlKeepAliveTimeout (was: Error with
org.apache.commons.net.ftp.FTPClient setControlKeepAliveTimeout)
> Error when using org.apache.commons.net.ftp.FTPClient
> setControlKeepAliveTimeout
>
>
> Key: NET-584
> URL: https://issues.apache.org/jira/browse/NET-584
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Reporter: Kazantsev Andrey Sergeevich
>
> I have a question about using library commons-net-3.4.jar
> Question is about org.apache.commons.net.ftp.FTPClient method
> setControlKeepAliveTimeout.
> Read about using it on:
> https://commons.apache.org/proper/commons-net/apidocs/org/apache/commons/net/ftp/FTPClient.html
> When I use it in my code I get this error:
> {code}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:163)
> at java.net.SocketInputStream.read(SocketInputStream.java:133)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:322)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:364)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:210)
> at java.io.InputStreamReader.read(InputStreamReader.java:205)
> at java.io.BufferedReader.fill(BufferedReader.java:165)
> at java.io.BufferedReader.read(BufferedReader.java:186)
> at
> org.apache.commons.net.io.CRLFLineReader.readLine(CRLFLineReader.java:58)
> at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:313)
> at org.apache.commons.net.ftp.FTP.__getReplyNoReport(FTP.java:303)
> at org.apache.commons.net.ftp.FTPClient$CSL.cleanUp(FTPClient.java:3838)
> at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:695)
> at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:643)
> at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:2033)
> at ru.mdm.File.Transfer.FTP.PutRemoteFileBinary(FTP.java:192)
> at
> ru.mdm.File.Transfer.TimeLimit.Thread.Protocol.PutRemoteFileBinaryThread.actionsToExecute(PutRemoteFileBinaryThread.java:23)
> at
> ru.mdm.File.Transfer.TimeLimit.OperationThread.run(OperationThread.java:60)
> {code}
> Without enabling this option all works fine.
> Here is the code:
> {code}
> package ru.mdm.File.Transfer;
> import bin.ru.osa.common.utils.*;
> import java.util.List;
> import java.io.*;
> import com.ibm.broker.javacompute.MbJavaComputeNode;
> import com.ibm.broker.plugin.*;
> import org.apache.commons.net.ftp.*;
> import org.apache.commons.net.*;
> import ru.mdm.File.Transfer.Options.OptionsXMLProcessor;
> public class FTP implements Protocol
> {
>
> FTPClient client = new FTPClient();
>
> OptionsXMLProcessor optionsXMLProcessor;
>
>
> boolean st;
> String LastMessage = new String();
>
> boolean ignoreErrors = false;
>
>
> public FTP()
> {
> super();
> }
>
> protected void finalize() { disconnect(); }
>
> public void connect(String CntName,
> String Host,
> String Port,
> String L,
> String P) throws Exception
> {
> try
> {
> client.setControlKeepAliveTimeout(300);
> client.connect(Host);
> client.login(L, P);
> CheckState();
> }
> catch(Exception e)
> {
>LastMessage=client.getReplyString();
>if(LastMessage == null) LastMessage = e.getMessage();
>
>e.printStackTrace();
>
>throw e;
> }
> }
>
> public void disconnect()
> {
> try
> {
> if(client.isConnected())
> {
> client.logout();
> client.disconnect();
> }
> }
> catch(Exception e)
> {
> e.printStackTrace();
> }
> }
>
> public void chmod(String RemoteFile, String Rights) throws Exception
> {
> client.sendSiteCommand("chmod "+RemoteFile+" "+Rights);
> CheckState();
> }
>
>
>
[jira] [Updated] (LANG-1124) Add split by length methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-1124:
Assignee: (was: Loic Guibert)
> Add split by length methods in StringUtils
> --
>
> Key: LANG-1124
> URL: https://issues.apache.org/jira/browse/LANG-1124
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Loic Guibert
>
> Add methods to split a String by fixed lengths :
> {code:java}
> public static String[] splitByLength(String str, int ... lengths);
> public static String[] splitByLengthRepeatedly(String str, int ... lengths);
> {code}
> Detail :
> {code:java}
> /**
> * Split a String into an array, using an array of fixed string
> lengths.
> *
> * If not null String input, the returned array size is same as the input
> lengths array.
> *
> * A null input String returns {@code null}.
> * A {@code null} or empty input lengths array returns an empty array.
> * A {@code 0} in the input lengths array results in en empty string.
> *
> * Extra characters are ignored (ie String length greater than sum of
> split lengths).
> * All empty substrings other than zero length requested, are returned {@code
> null}.
> *
> *
> * StringUtils.splitByLength(null, *) = null
> * StringUtils.splitByLength("abc")= []
> * StringUtils.splitByLength("abc", null) = []
> * StringUtils.splitByLength("abc", [])= []
> * StringUtils.splitByLength("", 2, 4, 1) = [null, null, null]
> *
> * StringUtils.splitByLength("abcdefg", 2, 4, 1) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdefghij", 2, 4, 1) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdefg", 2, 4, 5) = ["ab", "cdef", "g"]
> * StringUtils.splitByLength("abcdef", 2, 4, 1) = ["ab", "cdef", null]
> *
> * StringUtils.splitByLength(" abcdef", 2, 4, 1) = [" a", "bcde", "f"]
> * StringUtils.splitByLength("abcdef ", 2, 4, 1) = ["ab", "cdef", " "]
> * StringUtils.splitByLength("abcdefg", 2, 4, 0, 1) = ["ab", "cdef", "", "g"]
> * StringUtils.splitByLength("abcdefg", -1) = {@link
> IllegalArgumentException}
> *
> *
> * @param str the String to parse, may be null
> * @param lengths the string lengths where to cut, may be null, must not be
> negative
> * @return an array of splitted Strings, {@code null} if null String input
> * @throws IllegalArgumentException
> * if one of the lengths is negative
> */
> public static String[] splitByLength(String str, int ... lengths);
> /**
> * Split a String into an array, using an array of fixed string lengths
> repeated as
> * many times as necessary to reach the String end.
> *
> * If not null String input, the returned array size is a multiple of the
> input lengths array.
> *
> * A null input String returns {@code null}.
> * A {@code null} or empty input lengths array returns an empty array.
> * A {@code 0} in the input lengths array results in en empty string.
> *
> * All empty substrings other than zero length requested and following
> substrings,
> * are returned {@code null}.
> *
> *
> * StringUtils.splitByLengthRepeated(null, *) = null
> * StringUtils.splitByLengthRepeated("abc")= []
> * StringUtils.splitByLengthRepeated("abc", null) = []
> * StringUtils.splitByLengthRepeated("abc", [])= []
> * StringUtils.splitByLengthRepeated("", 2, 4, 1) = [null, null, null]
> *
> * StringUtils.splitByLengthRepeated("abcdefghij", 2, 3) = ["ab", "cde",
> "fg", "hij"]
> * StringUtils.splitByLengthRepeated("abcdefgh", 2, 3) = ["ab", "cde",
> "fg", "h"]
> * StringUtils.splitByLengthRepeated("abcdefg", 2, 3)= ["ab", "cde",
> "fg", null]
> *
> * StringUtils.splitByLengthRepeated(" abcdef", 2, 3)= [" a", "bcd",
> "ef", null]
> * StringUtils.splitByLengthRepeated("abcdef ", 2, 3)= ["ab", "cde",
> "f ", null]
> * StringUtils.splitByLengthRepeated("abcdef", 2, 3, 0, 1) = ["ab", "cde",
> "", "f"]
> * StringUtils.splitByLengthRepeated("abcdefg", 2, 3, 0, 1) = ["ab", "cde",
> "", "f",
> * "g", null,
> null, null]
> * StringUtils.splitByLengthRepeated("abcdefgh", 2, 0, 1, 0) = ["ab", "",
> "c", "",
> * "de", "",
> "f", "",
> * "gh", "",
> null, null]
> * StringUtils.splitByLengthRepeated("abcdefg", 2, 0, 1, 0) = ["ab", "", "c",
> "",
> * "de", "",
> "f", "",
> * "g", null,
> null, null]
> * StringUtils.splitByLengthRepeated("abcdefg", -1) = {@link
> IllegalArgumentException}
> *
[GitHub] commons-lang issue #253: Added a restart method for convenience
Github user esend7881 commented on the issue: https://github.com/apache/commons-lang/pull/253 @PascalSchumacher good point. I would say the main advantage is my method would not have the JVM re-create an object. So if you are restarting the timer over and over, it may be less costly. In the end, same outcome. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #253: Added a restart method for convenience
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/253 Hi @esend7881 thanks for the pull request. I'm not sure it is a good idea to add at method that is nearly identical to `StopWatch#createStarted`. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (FILEUPLOAD-254) Improve MultipartStream public API
[
https://issues.apache.org/jira/browse/FILEUPLOAD-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932497#comment-15932497
]
Dmitry Katsubo commented on FILEUPLOAD-254:
---
I vote for this improvement. I think the issue is similar to FILEUPLOAD-278. I
would suggest the method name like:
{code}
public InputStream getBodyDataInputStream();
{code}
or simply
{code}
public InputStream getInputStream();
{code}
> Improve MultipartStream public API
> --
>
> Key: FILEUPLOAD-254
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-254
> Project: Commons FileUpload
> Issue Type: Improvement
>Affects Versions: 1.3.1
>Reporter: Anton Gorbunov
>Assignee: Jochen Wiedmann
>
> In many cases user may need to get part content as an InputStream.
> MultipartStream class already has such method - newInputStream(), but for
> some reason it made package-private.
> I suggest to make it public.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user sebbASF commented on the issue: https://github.com/apache/commons-lang/pull/231 Also it occurs to me that ProcessorArch and ProcessorType could perhaps be subtypes of Processor (Arch and Type). They don't really have an independent existence, so do they need separate classes? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user sebbASF commented on the issue:
https://github.com/apache/commons-lang/pull/231
Agreed it's not necessary to have the isXXX methods.
However it makes the user code shorter and simpler.
Currently the code is:
```
Processor processor = ArchUtils.getProcessor();
if (ProcessorArch.BIT_32.equals(processor.getProcessorArch())) {}
if (ProcessorType.PPC.equals(processor.getProcessorType())) {}
```
It would become:
```
Processor processor = ArchUtils.getProcessor();
if (processor.is32Bit()) {}
if (processor.isPPC()) {}
```
As well as being longer, in the first case one has to remember to whether
to use ProcessorArch or ProcessorType
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: (was: commons-collections.java7.build.log) > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: (was: commons-collections.java8.build.log) > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: commons-collections.java7.build.log commons-collections.java8.build.log > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: (was: commons-collections.java8.build.log) > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: commons-collections.java7.build.log > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: commons-collections.java8.build.log > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Comment: was deleted (was: Unsuccessful build with Java 8) > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java7.build.log, > commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #231: Evaluate Architecure
Github user sebbASF commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/231#discussion_r106870483
--- Diff: src/test/java/org/apache/commons/lang3/ArchUtilsTest.java ---
@@ -0,0 +1,131 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3;
+
+import org.apache.commons.lang3.arch.Processor;
+import org.apache.commons.lang3.arch.ProcessorArch;
+import org.junit.Test;
+
+import static org.junit.Assert.assertTrue;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertNull;
+import static org.junit.Assert.assertNotNull;
+
+/**
+ * Test class for {@link ArchUtils}.
+ *
+ * @author Tomschi
+ */
+public class ArchUtilsTest {
+
+// x86
+private static final String X86 = "x86";
+private static final String X86_I386 = "i386";
+private static final String X86_I486 = "i486";
+private static final String X86_I586 = "i586";
+private static final String X86_I686 = "i686";
+private static final String X86_PENTIUM = "pentium";
+
+// x86_64
+private static final String X86_64 = "x86_64";
+private static final String X86_64_AMD64 = "amd64";
+private static final String X86_64_EM64T = "em64t";
+private static final String X86_64_UNIVERSAL = "universal";
+
+// IA64
+private static final String IA64 = "ia64";
+private static final String IA64W = "ia64w";
+
+// IA64_32
+private static final String IA64_32 = "ia64_32";
+private static final String IA64N = "ia64n";
+
+// PPC
+private static final String PPC = "ppc";
+private static final String POWER = "power";
+private static final String POWERPC = "powerpc";
+private static final String POWER_PC = "power_pc";
+private static final String POWER_RS = "power_rs";
+
+// PPC 64
+private static final String PPC64 = "ppc64";
+private static final String POWER64 = "power64";
+private static final String POWERPC64 = "powerpc64";
+private static final String POWER_PC64 = "power_pc64";
+private static final String POWER_RS64 = "power_rs64";
+
+@Test
+public void testIs32BitJVM() {
+Processor processor = ArchUtils.getProcessor(X86);
+assertNotNull(processor);
+
assertTrue(ProcessorArch.BIT_32.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(IA64_32);
+assertNotNull(processor);
+
assertTrue(ProcessorArch.BIT_32.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(PPC);
+assertNotNull(processor);
+
assertTrue(ProcessorArch.BIT_32.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(X86_64);
+assertNotNull(processor);
+
assertFalse(ProcessorArch.BIT_32.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(PPC64);
+assertNotNull(processor);
+
assertFalse(ProcessorArch.BIT_32.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(IA64);
+assertNotNull(processor);
+
assertFalse(ProcessorArch.BIT_32.equals(processor.getProcessorArch()));
+}
+
+@Test
+public void testIs64BitJVM() {
+Processor processor = ArchUtils.getProcessor(X86_64);
+assertNotNull(processor);
+
assertTrue(ProcessorArch.BIT_64.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(PPC64);
+assertNotNull(processor);
+
assertTrue(ProcessorArch.BIT_64.equals(processor.getProcessorArch()));
+
+processor = ArchUtils.getProcessor(IA64);
+assertNotNull(processor);
+
assertTrue(ProcessorArch.BIT_64.equals(processor.getProcessorArch()));
+
+
[jira] [Updated] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
[ https://issues.apache.org/jira/browse/COLLECTIONS-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allon Mureinik updated COLLECTIONS-601: --- Attachment: commons-collections.java8.build.log Unsuccessful build with Java 8 > commons-collections unit tests broken in Java 8 > --- > > Key: COLLECTIONS-601 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 > Project: Commons Collections > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full > details in attached logs >Reporter: Allon Mureinik > Labels: test > Attachments: commons-collections.java8.build.log > > > Building the upstream trunk (currently, patch 30b2aca) fails the unit tests > in Java 8, but passes in Java 7 on the same machine. Attached logs with env > details an errors of a successful Java 7 build and an unsuccessful Java 8 > build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (COLLECTIONS-601) commons-collections unit tests broken in Java 8
Allon Mureinik created COLLECTIONS-601: -- Summary: commons-collections unit tests broken in Java 8 Key: COLLECTIONS-601 URL: https://issues.apache.org/jira/browse/COLLECTIONS-601 Project: Commons Collections Issue Type: Bug Affects Versions: Nightly Builds Environment: Maven 3.3.9, Java 1.8.0-121-1.b14, Fedora 25 - full details in attached logs Reporter: Allon Mureinik Building the upstream trunk (currently, patch 30b2aca) fails the unit tests in Java 8, but passes in Java 7 on the same machine. Attached logs with env details an errors of a successful Java 7 build and an unsuccessful Java 8 build -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/231 [](https://coveralls.io/builds/10673667) Coverage increased (+0.02%) to 94.589% when pulling **dbdb045c46294191245672bad6f062ba00fbfb70 on Tomschi:master** into **5d6c176388e417869421adf2eb21ac5c291f0884 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/231 [](https://coveralls.io/builds/10673667) Coverage increased (+0.02%) to 94.589% when pulling **dbdb045c46294191245672bad6f062ba00fbfb70 on Tomschi:master** into **5d6c176388e417869421adf2eb21ac5c291f0884 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user Tomschi commented on the issue: https://github.com/apache/commons-lang/pull/231 I'm not sure, if we really need the isXXX methods in the Processor class, because i can directly equal the enums. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
