[jira] [Commented] (NET-584) Error with org.apache.commons.net.ftp.FTPClient

[Nick Manley (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905925#comment-15905925
 ] 

Nick Manley commented on NET-584:
-

Hey, Sebb. Thank you for the prompt response. I had some time to look at this 
today while I was at work. I dug into some of the code to better understand 
what it was doing and I think I misunderstood what the controlKeepAlive was 
doing.

bq. The method only affects the behaviour with certain retrieve/store methods 
(as per the Javadoc).

I didn't realize that at first. I thought it was something that happens 
continuously. As in, a NoOp would get sent every X seconds from the time I 
connect to the time I disconnect.

bq. If it does not help, then don't use it - not all FTP servers support 
control connection communication whilst a transfer is in progress.

I didn't know this either. I was under the impression that if I had a long 
upload, I had to do something to keep the control connection alive or it would 
time out. Removing the setControlKeepAliveTimeout had the opposite effect I was 
expecting. I thought for sure that without it, the control connection would 
timeout during a long upload. That doesn't seem to be the case though.

bq. However I don't understand why this worked in 3.3 but does not in 3.5.

Could have just been an issue of me not uploading a large enough file to 
trigger it. Don't take that to mean the issue doesn't exist in 3.3, just that I 
didn't happen to see it trigger when I was testing out different versions.

bq. Maybe the code should ignore SocketTimeoutException at this point in case 
the responses were lost.

Maybe. But it looks like the exception is being triggered when it's reading the 
reply. Prior to that, the {{CSL}} class is trying to clean-up any outstanding 
NoOps. I think that's the part that might be exhausting the input stream and it 
maybe eating the transfer reply along the way. I don't know if ignoring the 
exception outright is the correct behavior.

After a bit more research and understanding, I'm willing to say that this 
probably isn't a bug in Commons Net; just a misuse on my part. I might suggest 
that some of the documentation on {{controlKeepAliveTimeout}} that exists on 
the {{FTPClient}} class also be put into the setter. That would make it more 
discoverable. Also, do you think it is worth adding to the javadoc what you 
said about not all FTP servers supporting simultaneous writing to the 
control/data socket? In some senses the javadoc sounds like it's saying "it's a 
good idea to use this" (a best practice to follow) rather than "use this if you 
have problems" (a workaround).

The original reporter seems to have had a similar misunderstanding as did the 
users on NET-486. I don't know how much work it would be to have the code 
handle this a bit nicer (either not throw an exception, or throw something 
nicer than "read timed out"). But if that proves to be too much of a hassle, 
then re-wording the javadocs would go a long way. Just something that would 
signify it as a workaround for particular users and not a best practice that 
someone should be doing.

> Error with org.apache.commons.net.ftp.FTPClient 
> 
>
> 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 

[jira] [Commented] (NET-584) Error with org.apache.commons.net.ftp.FTPClient

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905899#comment-15905899
 ] 

Sebb commented on NET-584:
--

SNAPSHOT commons-net-3.7-20170310.235330-8 posted to the Apache snapshot repo 
in case you want to try.
This should only be used for testing. Do not use on a production system. etc.

> Error with org.apache.commons.net.ftp.FTPClient 
> 
>
> 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();
>   }
>   
>   
>   public void 

[jira] [Resolved] (NET-624) SubnetInfo#toCidrNotation - a wrong format subnet mask is allows

[Sebb (JIRA)]

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

Sebb resolved NET-624.
--
   Resolution: Fixed
Fix Version/s: 3.7

Thanks, fixed (with some added tests):

URL: http://svn.apache.org/viewvc?rev=1786469=rev
Log:
NET-624 SubnetInfo#toCidrNotation - a wrong format subnet mask is allowed

Modified:
commons/proper/net/trunk/src/changes/changes.xml

commons/proper/net/trunk/src/main/java/org/apache/commons/net/util/SubnetUtils.java

commons/proper/net/trunk/src/test/java/org/apache/commons/net/SubnetUtilsTest.java


> SubnetInfo#toCidrNotation - a wrong format subnet mask is allows
> 
>
> Key: NET-624
> URL: https://issues.apache.org/jira/browse/NET-624
> Project: Commons Net
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Makoto Sakaguchi
> Fix For: 3.7
>
>
> An IPv4 subnet mask, which is also the network mask, must consist of a set of 
> contiguous 1-bits followed by a block of 0-bits (i.e. 255.255.255.0), but it 
> does not check.
> {code}
> /* 255.255.0.1 is ...0001 in  binary */
> SubnetUtils su = new SubnetUtils("192.168.0.1", "255.255.0.1"); // expect 
> error
> SubnetInfo si = su.getInfo();
> System.out.println(si.getNetmask()); // Expect error or 255.255.0.1
> 255.255.128.0
> {code}
> https://github.com/apache/commons-net/pull/13



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NET-624) SubnetInfo#toCidrNotation - a wrong format subnet mask is allowed

[Sebb (JIRA)]

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

Sebb updated NET-624:
-
Summary: SubnetInfo#toCidrNotation - a wrong format subnet mask is allowed  
(was: SubnetInfo#toCidrNotation - a wrong format subnet mask is allows)

> SubnetInfo#toCidrNotation - a wrong format subnet mask is allowed
> -
>
> Key: NET-624
> URL: https://issues.apache.org/jira/browse/NET-624
> Project: Commons Net
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Makoto Sakaguchi
> Fix For: 3.7
>
>
> An IPv4 subnet mask, which is also the network mask, must consist of a set of 
> contiguous 1-bits followed by a block of 0-bits (i.e. 255.255.255.0), but it 
> does not check.
> {code}
> /* 255.255.0.1 is ...0001 in  binary */
> SubnetUtils su = new SubnetUtils("192.168.0.1", "255.255.0.1"); // expect 
> error
> SubnetInfo si = su.getInfo();
> System.out.println(si.getNetmask()); // Expect error or 255.255.0.1
> 255.255.128.0
> {code}
> https://github.com/apache/commons-net/pull/13



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (NET-623) SubnetUtils - fixed spelling errors

[Sebb (JIRA)]

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

Sebb resolved NET-623.
--
   Resolution: Fixed
Fix Version/s: 3.7

Thanks, applied:

URL: http://svn.apache.org/viewvc?rev=1786461=rev
Log:
NET-623 SubnetUtils - fixed spelling errors

Modified:
commons/proper/net/trunk/src/changes/changes.xml

commons/proper/net/trunk/src/main/java/org/apache/commons/net/util/SubnetUtils.java


> SubnetUtils - fixed spelling errors
> ---
>
> Key: NET-623
> URL: https://issues.apache.org/jira/browse/NET-623
> Project: Commons Net
>  Issue Type: Improvement
>Reporter: Makoto Sakaguchi
> Fix For: 3.7
>
>
> Fixed spelling errors in the API document.
> https://github.com/apache/commons-net/pull/14



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NET-584) Error with org.apache.commons.net.ftp.FTPClient

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905749#comment-15905749
 ] 

Sebb commented on NET-584:
--

The method only affects the behaviour with certain retrieve/store methods (as 
per the Javadoc).
If it does not help, then don't use it - not all FTP servers support control 
connection communication whilst a transfer is in progress.

It looks as though the code fails when it is trying to retrieve the outstanding 
NOOP responses after the data transfer has completed.

Maybe the code should ignore SocketTimeoutException at this point in case the 
responses were lost.
However I don't understand why this worked in 3.3 but does not in 3.5.

I can post a SNAPSHOT build with this change; it would be very helpful to know 
if this fixes the problem

> Error with org.apache.commons.net.ftp.FTPClient 
> 
>
> 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();  
>   

[GitHub] commons-lang pull request #231: Evaluate Architecure

[sebbASF]

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/231#discussion_r105472960
  
--- Diff: src/main/java/org/apache/commons/lang3/ArchUtils.java ---
@@ -0,0 +1,238 @@
+/*
+ * 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.apache.commons.lang3.arch.ProcessorType;
+
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+/**
+ * An utility class for the os.arch System Property. The class defines 
methods for
+ * identifying the architecture of the current JVM.
+ * 
+ * Important: The os.arch System Property returns the architecture used by 
the JVM
+ * not of the operating system.
+ * 
+ */
+public class ArchUtils {
+
+private static Map map;
+
+static {
+map = new HashMap<>();
+init();
+}
+
+private static final void init() {
+init_X86_32Bit();
+init_X86_64Bit();
+init_IA64_32Bit();
+init_IA64_64Bit();
+init_PPC_32Bit();
+init_PPC_64Bit();
+}
+
+/**
+ * Adding x86 32 bit {@link Processor}'s to the map
+ */
+private static final void init_X86_32Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.X86);
+addProcessors(Arrays.asList("x86", "i386", "i486", "i586", "i686", 
"pentium"), processor);
+}
+
+/**
+ * Adding x86 64 bit {@link Processor}'s to the map
+ */
+private static final void init_X86_64Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.X86);
+addProcessors(Arrays.asList("x86_64", "amd64", "em64t", 
"universal"), processor);
+}
+
+/**
+ * Adding ia64 32 bit {@link Processor}'s to the map
+ */
+private static final void init_IA64_32Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.IA_64);
+addProcessors(Arrays.asList("ia64_32", "ia64n"), processor);
+}
+
+/**
+ * Adding ia64 64 bit {@link Processor}'s to the map
+ */
+private static final void init_IA64_64Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.IA_64);
+addProcessors(Arrays.asList("ia64", "ia64w"), processor);
+}
+
+/**
+ * Adding PPC 32 bit {@link Processor}'s to the map
+ */
+private static final void init_PPC_32Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.PPC);
+addProcessors(Arrays.asList("ppc", "power", "powerpc", "power_pc", 
"power_rs"), processor);
+}
+
+/**
+ * Adding PPC 64 bit {@link Processor}'s to the map
+ */
+private static final void init_PPC_64Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.PPC);
+addProcessors(Arrays.asList("ppc64", "power64", "powerpc64", 
"power_pc64", "power_rs64"), processor);
+}
+
+/**
+ * Adds the given {@link Processor} whith the given key {@link String} 
to the map.
+ *
+ * @param key The key as {@link String}.
+ * @param processor The {@link Processor} to add.
+ * @throws UnsupportedOperationException When key already exists in 
map.
+ */
+private static final void addProcessor(String key, Processor 
processor) throws UnsupportedOperationException {
+if (!map.containsKey(key)) {
+map.put(key, processor);
+} else {
+String msg = "Key " + key + " already exists in processor map";
+throw new UnsupportedOperationException(msg);
+}
+}

[GitHub] commons-lang issue #231: Evaluate Architecure

[sebbASF]

Github user sebbASF commented on the issue:

https://github.com/apache/commons-lang/pull/231
  
In which case, I think they belong on the Processor class.

The user code would look like:
```
Processor proc = ArchUtils.getProcessor([String]);
if (proc != null) {
if (proc.isX86() && proc.isPPC()) {
}
} // else not supported
```

At present the same code is

```
if (ArchUtils.isSupported([String])) {
if (ArchUtils.isX86([String]) && ArchUtils.isPPC([String]) )
}
}
```
I think that looks more complicated. 
Also all the isXXX methods have to be overloaded with an optional string 
parameter.
And the map is accessed at least 3 times.


---
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 pull request #231: Evaluate Architecure

[sebbASF]

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/231#discussion_r105468080
  
--- Diff: src/main/java/org/apache/commons/lang3/ArchUtils.java ---
@@ -53,94 +55,76 @@ private static final void init() {
  * Adding x86 32 bit {@link Processor}'s to the map
  */
 private static final void init_X86_32Bit() {
-Processor x86 = new Processor("x86", ProcessorArch.BIT_32, 
ProcessorType.X86);
-Processor i386 = new Processor("i386", ProcessorArch.BIT_32, 
ProcessorType.X86);
-Processor i486 = new Processor("i486", ProcessorArch.BIT_32, 
ProcessorType.X86);
-Processor i586 = new Processor("i586", ProcessorArch.BIT_32, 
ProcessorType.X86);
-Processor i686 = new Processor("i686", ProcessorArch.BIT_32, 
ProcessorType.X86);
-Processor pentium = new Processor("pentium", ProcessorArch.BIT_32, 
ProcessorType.X86);
-addProcessors(x86, i386, i486, i586, i686, pentium);
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.X86);
+addProcessors(Arrays.asList("x86", "i386", "i486", "i586", "i686", 
"pentium"), processor);
 }
 
 /**
  * Adding x86 64 bit {@link Processor}'s to the map
  */
 private static final void init_X86_64Bit() {
-Processor x86_64 = new Processor("x86_64", ProcessorArch.BIT_64, 
ProcessorType.X86);
-Processor amd64 = new Processor("amd64", ProcessorArch.BIT_64, 
ProcessorType.X86);
-Processor em64t = new Processor("em64t", ProcessorArch.BIT_64, 
ProcessorType.X86);
-Processor universal = new Processor("universal", 
ProcessorArch.BIT_64, ProcessorType.X86);
-addProcessors(x86_64, amd64, em64t, universal);
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.X86);
+addProcessors(Arrays.asList("x86_64", "amd64", "em64t", 
"universal"), processor);
 }
 
 /**
  * Adding ia64 32 bit {@link Processor}'s to the map
  */
 private static final void init_IA64_32Bit() {
-Processor ia64_32 = new Processor("ia64_32", ProcessorArch.BIT_32, 
ProcessorType.IA_64);
-Processor ia64n = new Processor("ia64n", ProcessorArch.BIT_32, 
ProcessorType.IA_64);
-addProcessors(ia64_32, ia64n);
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.IA_64);
+addProcessors(Arrays.asList("ia64_32", "ia64n"), processor);
 }
 
 /**
  * Adding ia64 64 bit {@link Processor}'s to the map
  */
 private static final void init_IA64_64Bit() {
-Processor ia64 = new Processor("ia64", ProcessorArch.BIT_64, 
ProcessorType.IA_64);
-Processor ia64w = new Processor("ia64w", ProcessorArch.BIT_64, 
ProcessorType.IA_64);
-addProcessors(ia64, ia64w);
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.IA_64);
+addProcessors(Arrays.asList("ia64", "ia64w"), processor);
 }
 
 /**
  * Adding PPC 32 bit {@link Processor}'s to the map
  */
 private static final void init_PPC_32Bit() {
-Processor ppc = new Processor("ppc", ProcessorArch.BIT_32, 
ProcessorType.PPC);
-Processor power = new Processor("power", ProcessorArch.BIT_32, 
ProcessorType.PPC);
-Processor powerpc = new Processor("powerpc", ProcessorArch.BIT_32, 
ProcessorType.PPC);
-Processor power_pc = new Processor("power_pc", 
ProcessorArch.BIT_32, ProcessorType.PPC);
-Processor power_rs = new Processor("power_rs", 
ProcessorArch.BIT_32, ProcessorType.PPC);
-addProcessors(ppc, power, powerpc, power_pc, power_rs);
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.PPC);
+addProcessors(Arrays.asList("ppc", "power", "powerpc", "power_pc", 
"power_rs"), processor);
 }
 
 /**
  * Adding PPC 64 bit {@link Processor}'s to the map
  */
 private static final void init_PPC_64Bit() {
-Processor ppc64 = new Processor("ppc64", ProcessorArch.BIT_64, 
ProcessorType.PPC);
-Processor power64 = new Processor("power64", ProcessorArch.BIT_64, 
ProcessorType.PPC);
-Processor powerpc64 = new Processor("powerpc64", 
ProcessorArch.BIT_64, ProcessorType.PPC);
-Processor power_pc64 = new Processor("power_pc64", 
ProcessorArch.BIT_64, ProcessorType.PPC);
-Processor power_rs64 = new Processor("power_rs64", 
ProcessorArch.BIT_64, ProcessorType.PPC);
-addProcessors(ppc64, power64, powerpc64, power_pc64, power_rs64);
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.PPC);
+addProcessors(Arrays.asList("ppc64", 

[jira] [Commented] (COMMONSRDF-60) Upgrade to latest commons parent

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905428#comment-15905428
 ] 

ASF GitHub Bot commented on COMMONSRDF-60:
--

GitHub user acoburn opened a pull request:

https://github.com/apache/commons-rdf/pull/34

COMMONSRDF-60: update commons-parent version

This upgrades the parent pom to the latest version of `commons-parent`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/acoburn/commons-rdf COMMONSRDF-60

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-rdf/pull/34.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #34


commit 5b03234a13560706575d6ddb9db493811d5181f2
Author: Aaron Coburn 
Date:   2017-03-10T17:14:57Z

COMMONSRDF-60: update commons-parent version




> Upgrade to latest commons parent
> 
>
> Key: COMMONSRDF-60
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-60
> Project: Apache Commons RDF
>  Issue Type: Improvement
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Aaron Coburn
>Priority: Trivial
>
> The latest version of commons-parent is 42. The code currently uses 41



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (COMMONSRDF-60) Upgrade to latest commons parent

[Aaron Coburn (JIRA)]

Aaron Coburn created COMMONSRDF-60:
--

 Summary: Upgrade to latest commons parent
 Key: COMMONSRDF-60
 URL: https://issues.apache.org/jira/browse/COMMONSRDF-60
 Project: Apache Commons RDF
  Issue Type: Improvement
  Components: api
Affects Versions: 0.3.0
Reporter: Aaron Coburn
Priority: Trivial


The latest version of commons-parent is 42. The code currently uses 41



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMMONSRDF-59) Fix javadocs warnings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905415#comment-15905415
 ] 

ASF GitHub Bot commented on COMMONSRDF-59:
--

GitHub user acoburn opened a pull request:

https://github.com/apache/commons-rdf/pull/33

COMMONSRDF-59 - fix minor javadocs warnings

This add some missing `@return` values, fixes an HTML error and adds some 
text to two otherwise undocumented parameters.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/acoburn/commons-rdf COMMONSRDF-59

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-rdf/pull/33.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #33


commit 18b5ecfc56cf1e37e752761bcaa694096fdcea04
Author: Aaron Coburn 
Date:   2017-03-10T17:05:26Z

COMMONSRDF-59 - fix minor javadocs warnings




> Fix javadocs warnings
> -
>
> Key: COMMONSRDF-59
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-59
> Project: Apache Commons RDF
>  Issue Type: Improvement
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Aaron Coburn
>Priority: Minor
>  Labels: documentation
> Fix For: 1.0.0
>
>
> There are some minor javadoc warnings related to commons.rdf.api.RDFSyntax.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (COMMONSRDF-59) Fix javadocs warnings

[Aaron Coburn (JIRA)]

Aaron Coburn created COMMONSRDF-59:
--

 Summary: Fix javadocs warnings
 Key: COMMONSRDF-59
 URL: https://issues.apache.org/jira/browse/COMMONSRDF-59
 Project: Apache Commons RDF
  Issue Type: Improvement
  Components: api
Affects Versions: 0.3.0
Reporter: Aaron Coburn
Priority: Minor
 Fix For: 1.0.0


There are some minor javadoc warnings related to commons.rdf.api.RDFSyntax.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (JEXL-220) Release 3.1 to Maven Repository

[Henri Biestro (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15901845#comment-15901845
 ] 

Henri Biestro edited comment on JEXL-220 at 3/10/17 5:02 PM:
-

There are 3 errors flagged by Clirr that preclude releasing:

1 - Method 'public java.lang.Boolean isCancellable()' has been added to an 
interfaceorg.apache.commons.jexl3.JexlEngine$Options
2 - Method 'public java.util.concurrent.Callable 
callable(org.apache.commons.jexl3.JexlContext)' has been added to an interface 
org.apache.commons.jexl3.JexlExpression
3 - Method 'public java.util.Map getPragmas()' has been added to an interface   
org.apache.commons.jexl3.JxltEngine$Template

None of these are supposed to be implemented by '3rd parties'; these are just 
intended to shield the (sole Jexl internal) implementation.


was (Author: henrib):
There are 3 errors flagged by Clirr that preclude releasing:

1 - Method 'public java.lang.Boolean isCancellable()' has been added to an 
interfaceorg.apache.commons.jexl3.JexlEngine$Options
2 - Method 'public java.util.concurrent.Callable 
callable(org.apache.commons.jexl3.JexlContext)' has been added to an interface 
org.apache.commons.jexl3.JexlExpression
3 - Method 'public java.util.Map getPragmas()' has been added to an interface   
org.apache.commons.jexl3.JxltEngine$Template

None of these are supposed to be implemented by '3rd parties'; these are just 
intended to shield the (sole Jexl internal) implementation.

> Release 3.1 to Maven Repository
> ---
>
> Key: JEXL-220
> URL: https://issues.apache.org/jira/browse/JEXL-220
> Project: Commons JEXL
>  Issue Type: Wish
>Affects Versions: 3.1
>Reporter: Doug Whitehead
>Priority: Minor
>
> Any chance version 3.1 is scheduled for a release to the Maven Repository any 
> time soon? Seems like there are plenty of improvements and bug fixes to 
> warrant a release, and also -- last release was a year go at this point :)
> https://mvnrepository.com/artifact/org.apache.commons/commons-jexl3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (JEXL-220) Release 3.1 to Maven Repository

[Henri Biestro (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15901845#comment-15901845
 ] 

Henri Biestro edited comment on JEXL-220 at 3/10/17 4:31 PM:
-

There are 3 errors flagged by Clirr that preclude releasing:

1 - Method 'public java.lang.Boolean isCancellable()' has been added to an 
interfaceorg.apache.commons.jexl3.JexlEngine$Options
2 - Method 'public java.util.concurrent.Callable 
callable(org.apache.commons.jexl3.JexlContext)' has been added to an interface 
org.apache.commons.jexl3.JexlExpression
3 - Method 'public java.util.Map getPragmas()' has been added to an interface   
org.apache.commons.jexl3.JxltEngine$Template

None of these are supposed to be implemented by '3rd parties'; these are just 
intended to shield the (sole Jexl internal) implementation.


was (Author: henrib):
Unfortunately, some bug fixes/enhancements have broken binary compatibility 
(adding a method to an interface does that too).
These fixes must either be modified to avoid breaking compatibility or publish 
jexl3.1 in the jexl31 package.

> Release 3.1 to Maven Repository
> ---
>
> Key: JEXL-220
> URL: https://issues.apache.org/jira/browse/JEXL-220
> Project: Commons JEXL
>  Issue Type: Wish
>Affects Versions: 3.1
>Reporter: Doug Whitehead
>Priority: Minor
>
> Any chance version 3.1 is scheduled for a release to the Maven Repository any 
> time soon? Seems like there are plenty of improvements and bug fixes to 
> warrant a release, and also -- last release was a year go at this point :)
> https://mvnrepository.com/artifact/org.apache.commons/commons-jexl3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #253: Added a restart method for convenience

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/253
  

[![Coverage 
Status](https://coveralls.io/builds/10532505/badge)](https://coveralls.io/builds/10532505)

Coverage increased (+0.01%) to 94.54% when pulling 
**d6f3109985eec112acb1584d3561c04ca9a76b9b on esend7881:master** into 
**ee19f8247c4bc0335ad3efe212dc0bdce97e2034 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 #253: Added a restart method for convenience

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/253
  

[![Coverage 
Status](https://coveralls.io/builds/10532505/badge)](https://coveralls.io/builds/10532505)

Coverage increased (+0.01%) to 94.54% when pulling 
**d6f3109985eec112acb1584d3561c04ca9a76b9b on esend7881:master** into 
**ee19f8247c4bc0335ad3efe212dc0bdce97e2034 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.
---

[jira] [Comment Edited] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils

[Rob Tompkins (JIRA)]

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

Rob Tompkins edited comment on LANG-1300 at 3/10/17 3:11 PM:
-

Github user chtompki commented on the issue:

https://github.com/apache/commons-lang/pull/251
  
@dmjones500 - you think we should bubble this up to the dev list?

Personally I'm ok with either approach, code unit v. code point, just so long 
as we are consistent across all of the CharSequence implementations.



was (Author: githubbot):
Github user chtompki commented on the issue:

https://github.com/apache/commons-lang/pull/251
  
@dmjones500 - you think we should bubble this up to the dev list?


> Clarify or improve behaviour of int-based methods in StringUtils
> 
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int 
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method 
> can handle supplementary characters. However, the current behaviour of these 
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by 
> this class to convert all {{CharSequence}} parameters to strings, enabling 
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LANG-1300:
--

Github user chtompki commented on the issue:

https://github.com/apache/commons-lang/pull/251
  
@dmjones500 - you think we should bubble this up to the dev list?


> Clarify or improve behaviour of int-based methods in StringUtils
> 
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int 
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method 
> can handle supplementary characters. However, the current behaviour of these 
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by 
> this class to convert all {{CharSequence}} parameters to strings, enabling 
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...

[chtompki]

Github user chtompki commented on the issue:

https://github.com/apache/commons-lang/pull/251
  
@dmjones500 - you think we should bubble this up to the dev list?


---
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] [Resolved] (JEXL-211) Add callable method to JexlExpression interface

[Henri Biestro (JIRA)]

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

Henri Biestro resolved JEXL-211.

   Resolution: Fixed
Fix Version/s: 3.1

src/main/java/org/apache/commons/jexl3/JexlExpression.java

Committed revision 1786353.

> Add callable method to JexlExpression interface
> ---
>
> Key: JEXL-211
> URL: https://issues.apache.org/jira/browse/JEXL-211
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.1
>
>
> It would be convenient to have the following method
> {code}
>Callable callable(JexlContext context);
> {code}
> in both JexlExpression and JexlScript interfaces. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (JEXL-216) Improve parsing concurrency in multithreaded environment

[Henri Biestro (JIRA)]

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

Henri Biestro resolved JEXL-216.

   Resolution: Fixed
Fix Version/s: 3.1

Added reader/writer lock to cache held by soft reference;
Added logic to create temporary parser when main one is already busy (since 
parser is not reentrant)

src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/main/java/org/apache/commons/jexl3/internal/InterpreterBase.java
src/main/java/org/apache/commons/jexl3/internal/SoftCache.java
src/main/java/org/apache/commons/jexl3/internal/TemplateEngine.java

Revision: 1786352

> Improve parsing concurrency in multithreaded environment
> 
>
> Key: JEXL-216
> URL: https://issues.apache.org/jira/browse/JEXL-216
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.1
>
>
> At the moment the {{Engine.parse()}} method synchronizes on {{parser}} member 
> even if the caching is enabled and the actual parsing is not required, in 
> case of cache hit. This effectively serializes processing of scripts and 
> expressions in multithreaded scenario. The suggestion is to separate 
> synchronization on cache from synchronization on parser, with the latter only 
> being performed if actual parsing is required.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (JEXL-221) Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()

[Henri Biestro (JIRA)]

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

Henri Biestro resolved JEXL-221.

Resolution: Fixed

tryInvoke is protected from null properties.

src/main/java/org/apache/commons/jexl3/internal/Script.java
src/main/java/org/apache/commons/jexl3/internal/introspection/BooleanGetExecutor.java
src/main/java/org/apache/commons/jexl3/internal/introspection/DuckGetExecutor.java
src/main/java/org/apache/commons/jexl3/internal/introspection/DuckSetExecutor.java
src/main/java/org/apache/commons/jexl3/internal/introspection/IndexedType.java
src/main/java/org/apache/commons/jexl3/internal/introspection/MapGetExecutor.java
src/main/java/org/apache/commons/jexl3/internal/introspection/MapSetExecutor.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java

Committed revision 1786350.

> Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()
> -
>
> Key: JEXL-221
> URL: https://issues.apache.org/jira/browse/JEXL-221
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>
> I'm getting sporadic undefined property error when accessing hashmap by a 
> key. The stack trace tells the cause is NPE in MapGetExecutor.tryInvoke() at 
> the following line:
> {code}
> if (obj != null && method != null
> && objectClass.equals(obj.getClass())
> && (key == null || 
> property.getClass().equals(key.getClass( {
> {code}
> I have managed to overcome this issue by adding the following null check:
> {code}
> if (obj != null && method != null
> && objectClass.equals(obj.getClass())
> && (key == null || property != null && 
> property.getClass().equals(key.getClass( {
> {code}
> I have only vague understanding of how things work inside jexl with 
> tryInvoke() and unfortunately can not provide any test case for this, but it 
> has worked in my case, so if nobody have any objections please include the 
> fix in source tree.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JEXL-221) Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()

[Henri Biestro (JIRA)]

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

Henri Biestro updated JEXL-221:
---
Fix Version/s: 3.1

> Sporadic undefined property error caused by NPE at MapGetExecutor.tryInvoke()
> -
>
> Key: JEXL-221
> URL: https://issues.apache.org/jira/browse/JEXL-221
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> I'm getting sporadic undefined property error when accessing hashmap by a 
> key. The stack trace tells the cause is NPE in MapGetExecutor.tryInvoke() at 
> the following line:
> {code}
> if (obj != null && method != null
> && objectClass.equals(obj.getClass())
> && (key == null || 
> property.getClass().equals(key.getClass( {
> {code}
> I have managed to overcome this issue by adding the following null check:
> {code}
> if (obj != null && method != null
> && objectClass.equals(obj.getClass())
> && (key == null || property != null && 
> property.getClass().equals(key.getClass( {
> {code}
> I have only vague understanding of how things work inside jexl with 
> tryInvoke() and unfortunately can not provide any test case for this, but it 
> has worked in my case, so if nobody have any objections please include the 
> fix in source tree.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NET-584) Error with org.apache.commons.net.ftp.FTPClient

[Nick Manley (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905038#comment-15905038
 ] 

Nick Manley commented on NET-584:
-

I am having the same issue with version 3.5. It only happens on large file 
uploads (>1GB). I get the same error SocketTimeoutException: Read timed out. 
Removing the call to {{setControlKeepAliveTimeout}} was able to resolve the 
issue. I don't know how that will affect the control connection though and 
whether it may timeout at another time without the keep-alive. I was not able 
to reproduce the error with version 3.3.

> Error with org.apache.commons.net.ftp.FTPClient 
> 
>
> 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();
>   }
>   }   

[GitHub] commons-lang issue #231: Evaluate Architecure

[Tomschi]

Github user Tomschi commented on the issue:

https://github.com/apache/commons-lang/pull/231
  
> There's no point in having the isXXX() methods any more.
There just need to be methods to get the Processor.
If necessary, the Processor class could have isxxx methods on it.

This methods are for me an easy and null safe way for evaluating. Further, 
this methods are the reason, why i have done this pull request.


---
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

[sebbASF]

Github user sebbASF commented on the issue:

https://github.com/apache/commons-lang/pull/231
  
There's no point in having the isXXX() methods any more.
There just need to be methods to get the Processor.
If necessary, the Processor class could have isxxx methods on it.


---
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 pull request #231: Evaluate Architecure

[sebbASF]

Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/231#discussion_r105378662
  
--- Diff: src/main/java/org/apache/commons/lang3/arch/Processor.java ---
@@ -0,0 +1,30 @@
+package org.apache.commons.lang3.arch;
+
+/**
+ *
+ */
+public class Processor {
+
+private String name;
+private ProcessorArch processorArch;
+private ProcessorType processorType;
+
--- End diff --

I don't understand how the name field helps. 
It's obviously necessary to be able to get the Processor object from the 
name, but once you have the object, you know what the name is.
So why do you think the name is necessary?

The name field results in more objects being needed; if the name is not 
included then all the PPC+64 systems (e.g.) can share the same object in the 
init code.


---
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

[Tomschi]

Github user Tomschi commented on the issue:

https://github.com/apache/commons-lang/pull/231
  
> If there is no database entry, return a Process instance with enums which 
indicate "Unknown".
(Attribute enums would need an extra 'Unknown' entry).

I think it is better to return null, if the Processor doesn't exists. I 
added UNKNOWN to both enums, but UNKNOWN can also be used for a existing 
Processor. So it is hard to evaluate, if the Processor exists or not, when the 
properties UNKNOWN are used.


---
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 pull request #231: Evaluate Architecure

[Tomschi]

Github user Tomschi commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/231#discussion_r105353803
  
--- Diff: src/main/java/org/apache/commons/lang3/arch/Processor.java ---
@@ -0,0 +1,30 @@
+package org.apache.commons.lang3.arch;
+
+/**
+ *
+ */
+public class Processor {
+
+private String name;
+private ProcessorArch processorArch;
+private ProcessorType processorType;
+
--- End diff --

I think the name field is needed for better reuse of the Processor object.


---
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.
---