[jira] [Comment Edited] (NET-578) FTPS client through http proxy
[
https://issues.apache.org/jira/browse/NET-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650539#comment-14650539
]
Jefferson Madalena edited comment on NET-578 at 8/1/15 9:34 PM:
I downloaded the source code of commons-net 3.3 and implemented my own FTPS
through HTTP Proxy client.
It has a problem when calling the method keepAlive, is giving the exception
"java.net.SocketTimeoutException: Read timed out". I don't know what is causing
this error. For me is not a problem, because I'm not using this feature.
Follow implemented customizations:
In FTPClient.java I created the method:
protected int getDataTimeout()
{
return __dataTimeout;
}
In FTPSClient.java I created the method:
protected SSLContext getContext() {
return context;
}
Created the class FTPSHTTPClient.java (is attached).
Created the class FTPSHTTPClientTest.java for tests (is attached).
was (Author: jeffemada):
I downloaded the source code of commons-net 3.3 and implemented my own FTPS
client through HTTP Proxy.
It has a problem when calling the method keepAlive, is giving the exception
"java.net.SocketTimeoutException: Read timed out". I don't know what is causing
this error. For my implementation is ok, because I'm not using this feature.
Follow implemented customizations:
In FTPClient.java I created the method:
protected int getDataTimeout()
{
return __dataTimeout;
}
In FTPSClient.java I created the method:
protected SSLContext getContext() {
return context;
}
Created the class FTPSHTTPClient.java (is attached).
Created the class FTPSHTTPClientTest.java for tests (is attached).
> FTPS client through http proxy
> --
>
> Key: NET-578
> URL: https://issues.apache.org/jira/browse/NET-578
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
> Environment: Linux 3.0.101-0.21-default x86_64
> Java 1.8 update 45 64-bit
>Reporter: Jefferson Madalena
> Attachments: FTPSHTTPClient_source_code.zip
>
>
> I'm trying to develop a Java FTPS client using Apache Commons Net library. To
> run de code I'm using Java 8, update 45.
> The exception occurs when I'm invoking the method "retrieveFile". I'm not
> sure, but I belive the connection used to tranfer the file is not using the
> HTTP proxy specified in code.
> With FileZilla client I can tranfer files using the same configurations.
> How can I fix this problem?
> {code:title=My code|borderStyle=solid}
> // client with explicit security
> FTPSClient ftps = new FTPSClient(false);
> // HTTP proxy configuration
> Proxy proxy = new Proxy(Type.HTTP, new
> InetSocketAddress("", ));
> ftps.setProxy(proxy);
> // to show FTP commands in prompt
> ftps.addProtocolCommandListener(new PrintCommandListener(new
> PrintWriter(System.out), true));
> // disable remote host verification
> ftps.setRemoteVerificationEnabled(false);
> // trust in ALL
> ftps.setTrustManager(TrustManagerUtils.getAcceptAllTrustManager());
> // send keepAlive every 30 seconds
> ftps.setControlKeepAliveTimeout(10l);
> // data transfer timeout
> ftps.setDataTimeout(3);
> // connect
> ftps.connect("", );
> ftps.login("", "");
> // config
> ftps.setCharset(Charset.forName("UTF-8"));
> ftps.setBufferSize(0);
> ftps.setFileType(FTP.BINARY_FILE_TYPE);
> ftps.enterLocalPassiveMode();
> ftps.execPROT("P");
> // ... do some operations
> ftps.retrieveFile("/dir1/dir2/fileX.zip", new ByteArrayOutputStream());
> // close
> ftps.logout();
> ftps.disconnect();
> {code}
> The output:
> {noformat}
> 220 (vsFTPd 2.2.2)
> AUTH TLS
> 234 Proceed with negotiation.
> USER ***
> 331 Please specify the password.
> PASS ***
> 230 Login successful.
> TYPE I
> 200 Switching to Binary mode.
> PROT P
> 200 PROT now Private.
> PASV
> 227 Entering Passive Mode ().
> Exception in thread "main" java.net.ConnectException: Connection timed out:
> connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:656)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:894)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:600)
> at org.apache
[jira] [Comment Edited] (NET-578) FTPS client through http proxy
[
https://issues.apache.org/jira/browse/NET-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650539#comment-14650539
]
Jefferson Madalena edited comment on NET-578 at 8/1/15 9:28 PM:
I downloaded the source code of commons-net 3.3 and implemented my own FTPS
client through HTTP Proxy.
It has a problem when calling the method keepAlive, is giving the exception
"java.net.SocketTimeoutException: Read timed out". I don't know what is causing
this error. For my implementation is ok, because I'm not using this feature.
Follow implemented customizations:
In FTPClient.java I created the method:
protected int getDataTimeout()
{
return __dataTimeout;
}
In FTPSClient.java I created the method:
protected SSLContext getContext() {
return context;
}
Created the class FTPSHTTPClient.java (is attached).
Created the class FTPSHTTPClientTest.java for tests (is attached).
was (Author: jeffemada):
I downloaded the source code of commons-net 3.3 and implemented my own FTPS
through HTTP Proxy client.
It has a problem when calling the method keepAlive, is giving the exception
"java.net.SocketTimeoutException: Read timed out". I don't know what is causing
this error. For my implementation is ok, because I'm not using this feature.
Follow implemented customizations:
In FTPClient.java I created the method:
protected int getDataTimeout()
{
return __dataTimeout;
}
In FTPSClient.java I created the method:
protected SSLContext getContext() {
return context;
}
Created the class FTPSHTTPClient.java (is attached).
Created the class FTPSHTTPClientTest.java for tests (is attached).
> FTPS client through http proxy
> --
>
> Key: NET-578
> URL: https://issues.apache.org/jira/browse/NET-578
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
> Environment: Linux 3.0.101-0.21-default x86_64
> Java 1.8 update 45 64-bit
>Reporter: Jefferson Madalena
> Attachments: FTPSHTTPClient_source_code.zip
>
>
> I'm trying to develop a Java FTPS client using Apache Commons Net library. To
> run de code I'm using Java 8, update 45.
> The exception occurs when I'm invoking the method "retrieveFile". I'm not
> sure, but I belive the connection used to tranfer the file is not using the
> HTTP proxy specified in code.
> With FileZilla client I can tranfer files using the same configurations.
> How can I fix this problem?
> {code:title=My code|borderStyle=solid}
> // client with explicit security
> FTPSClient ftps = new FTPSClient(false);
> // HTTP proxy configuration
> Proxy proxy = new Proxy(Type.HTTP, new
> InetSocketAddress("", ));
> ftps.setProxy(proxy);
> // to show FTP commands in prompt
> ftps.addProtocolCommandListener(new PrintCommandListener(new
> PrintWriter(System.out), true));
> // disable remote host verification
> ftps.setRemoteVerificationEnabled(false);
> // trust in ALL
> ftps.setTrustManager(TrustManagerUtils.getAcceptAllTrustManager());
> // send keepAlive every 30 seconds
> ftps.setControlKeepAliveTimeout(10l);
> // data transfer timeout
> ftps.setDataTimeout(3);
> // connect
> ftps.connect("", );
> ftps.login("", "");
> // config
> ftps.setCharset(Charset.forName("UTF-8"));
> ftps.setBufferSize(0);
> ftps.setFileType(FTP.BINARY_FILE_TYPE);
> ftps.enterLocalPassiveMode();
> ftps.execPROT("P");
> // ... do some operations
> ftps.retrieveFile("/dir1/dir2/fileX.zip", new ByteArrayOutputStream());
> // close
> ftps.logout();
> ftps.disconnect();
> {code}
> The output:
> {noformat}
> 220 (vsFTPd 2.2.2)
> AUTH TLS
> 234 Proceed with negotiation.
> USER ***
> 331 Please specify the password.
> PASS ***
> 230 Login successful.
> TYPE I
> 200 Switching to Binary mode.
> PROT P
> 200 PROT now Private.
> PASV
> 227 Entering Passive Mode ().
> Exception in thread "main" java.net.ConnectException: Connection timed out:
> connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:656)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:894)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:600)
> at org.ap
[jira] [Updated] (NET-578) FTPS client through http proxy
[
https://issues.apache.org/jira/browse/NET-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jefferson Madalena updated NET-578:
---
Attachment: FTPSHTTPClient_source_code.zip
I downloaded the source code of commons-net 3.3 and implemented my own FTPS
through HTTP Proxy client.
It has a problem when calling the method keepAlive, is giving the exception
"java.net.SocketTimeoutException: Read timed out". I don't know what is causing
this error. For my implementation is ok, because I'm not using this feature.
Follow implemented customizations:
In FTPClient.java I created the method:
protected int getDataTimeout()
{
return __dataTimeout;
}
In FTPSClient.java I created the method:
protected SSLContext getContext() {
return context;
}
Created the class FTPSHTTPClient.java (is attached).
Created the class FTPSHTTPClientTest.java for tests (is attached).
> FTPS client through http proxy
> --
>
> Key: NET-578
> URL: https://issues.apache.org/jira/browse/NET-578
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.3
> Environment: Linux 3.0.101-0.21-default x86_64
> Java 1.8 update 45 64-bit
>Reporter: Jefferson Madalena
> Attachments: FTPSHTTPClient_source_code.zip
>
>
> I'm trying to develop a Java FTPS client using Apache Commons Net library. To
> run de code I'm using Java 8, update 45.
> The exception occurs when I'm invoking the method "retrieveFile". I'm not
> sure, but I belive the connection used to tranfer the file is not using the
> HTTP proxy specified in code.
> With FileZilla client I can tranfer files using the same configurations.
> How can I fix this problem?
> {code:title=My code|borderStyle=solid}
> // client with explicit security
> FTPSClient ftps = new FTPSClient(false);
> // HTTP proxy configuration
> Proxy proxy = new Proxy(Type.HTTP, new
> InetSocketAddress("", ));
> ftps.setProxy(proxy);
> // to show FTP commands in prompt
> ftps.addProtocolCommandListener(new PrintCommandListener(new
> PrintWriter(System.out), true));
> // disable remote host verification
> ftps.setRemoteVerificationEnabled(false);
> // trust in ALL
> ftps.setTrustManager(TrustManagerUtils.getAcceptAllTrustManager());
> // send keepAlive every 30 seconds
> ftps.setControlKeepAliveTimeout(10l);
> // data transfer timeout
> ftps.setDataTimeout(3);
> // connect
> ftps.connect("", );
> ftps.login("", "");
> // config
> ftps.setCharset(Charset.forName("UTF-8"));
> ftps.setBufferSize(0);
> ftps.setFileType(FTP.BINARY_FILE_TYPE);
> ftps.enterLocalPassiveMode();
> ftps.execPROT("P");
> // ... do some operations
> ftps.retrieveFile("/dir1/dir2/fileX.zip", new ByteArrayOutputStream());
> // close
> ftps.logout();
> ftps.disconnect();
> {code}
> The output:
> {noformat}
> 220 (vsFTPd 2.2.2)
> AUTH TLS
> 234 Proceed with negotiation.
> USER ***
> 331 Please specify the password.
> PASS ***
> 230 Login successful.
> TYPE I
> 200 Switching to Binary mode.
> PROT P
> 200 PROT now Private.
> PASV
> 227 Entering Passive Mode ().
> Exception in thread "main" java.net.ConnectException: Connection timed out:
> connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:656)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:894)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:600)
> at org.apache.commons.net.ftp.FTPClient._retrieveFile(FTPClient.java:1854)
> at org.apache.commons.net.ftp.FTPClient.retrieveFile(FTPClient.java:1845)
> at br.com.bat.crm.test.util.FTPSClientTest.main(FTPSClientTest.java:57)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JEXL-171) Map access operator does not work if key name clashes with map property name
[
https://issues.apache.org/jira/browse/JEXL-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650376#comment-14650376
]
Henri Biestro edited comment on JEXL-171 at 8/1/15 3:03 PM:
A cleaner solution:
- Reified the resolver strategy in JexlUberspect.ResolverStrategy.
- Made strategy member of Uberspect, filled at creation time; added option to
pass it down.
This allows implementing and using strategy without having to derive the
Uberspect.
Using the 'map' strategy is now as simple as:
{code}
JexlEngine jexl = new
JexlBuilder().strategy(JexlUberspect.MAP_STRATEGY).create();
{code}
src/main/java/org/apache/commons/jexl3/JexlBuilder.java
src/main/java/org/apache/commons/jexl3/internal/introspection/Uberspect.java
src/main/java/org/apache/commons/jexl3/introspection/JexlUberspect.java
src/main/java/org/apache/commons/jexl3/internal/introspection/SandboxUberspect.java
src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/test/java/org/apache/commons/jexl3/StrategyTest.java
src/test/java/org/apache/commons/jexl3/internal/introspection/DiscoveryTest.java
Revision: 1693711
// not strictly related (nitpicking on javadoc, moving testes around, etc):
src/main/java/org/apache/commons/jexl3/internal/Debugger.java
src/main/java/org/apache/commons/jexl3/internal/IntegerRange.java
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/main/java/org/apache/commons/jexl3/internal/LongRange.java
src/test/java/org/apache/commons/jexl3/ArithmeticTest.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java
was (Author: henrib):
A cleaner solution:
- Reified the resolver strategy in JexlUberspect.ResolverStrategy.
- Made strategy member of Uberspect, filled at creation time; added option to
pass it down.
This allows implementing and using strategy without having to derive the
Uberspect.
Using the 'map' strategy is now as simple as:
{code}
JexlEngine jexl = new
JexlBuilder().strategy(JexlUberspect.MAP_STRATEGY).create();
{code}
src/main/java/org/apache/commons/jexl3/JexlBuilder.java
src/main/java/org/apache/commons/jexl3/internal/introspection/Uberspect.java
src/main/java/org/apache/commons/jexl3/introspection/JexlUberspect.java
src/main/java/org/apache/commons/jexl3/internal/introspection/SandboxUberspect.java
src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/test/java/org/apache/commons/jexl3/StrategyTest.java
src/test/java/org/apache/commons/jexl3/internal/introspection/DiscoveryTest.java
Revision: 1693711
*** not strictly related (nitpicking on javadoc, moving testes around, etc):
src/main/java/org/apache/commons/jexl3/internal/Debugger.java
src/main/java/org/apache/commons/jexl3/internal/IntegerRange.java
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/main/java/org/apache/commons/jexl3/internal/LongRange.java
src/test/java/org/apache/commons/jexl3/ArithmeticTest.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java
> Map access operator does not work if key name clashes with map property name
>
>
> Key: JEXL-171
> URL: https://issues.apache.org/jira/browse/JEXL-171
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Critical
> Fix For: 3.0
>
>
> The following example returns *false*, according to documentation should
> return *2*.
> i = new ("java.util.HashMap"); i.a = 1; i["empty"] = 2; i["empty"]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JEXL-171) Map access operator does not work if key name clashes with map property name
[
https://issues.apache.org/jira/browse/JEXL-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-171.
Resolution: Fixed
A cleaner solution:
- Reified the resolver strategy in JexlUberspect.ResolverStrategy.
- Made strategy member of Uberspect, filled at creation time; added option to
pass it down.
This allows implementing and using strategy without having to derive the
Uberspect.
Using the 'map' strategy is now as simple as:
{code}
JexlEngine jexl = new
JexlBuilder().strategy(JexlUberspect.MAP_STRATEGY).create();
{code}
src/main/java/org/apache/commons/jexl3/JexlBuilder.java
src/main/java/org/apache/commons/jexl3/internal/introspection/Uberspect.java
src/main/java/org/apache/commons/jexl3/introspection/JexlUberspect.java
src/main/java/org/apache/commons/jexl3/internal/introspection/SandboxUberspect.java
src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/test/java/org/apache/commons/jexl3/StrategyTest.java
src/test/java/org/apache/commons/jexl3/internal/introspection/DiscoveryTest.java
Revision: 1693711
*** not strictly related (nitpicking on javadoc, moving testes around, etc):
src/main/java/org/apache/commons/jexl3/internal/Debugger.java
src/main/java/org/apache/commons/jexl3/internal/IntegerRange.java
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/main/java/org/apache/commons/jexl3/internal/LongRange.java
src/test/java/org/apache/commons/jexl3/ArithmeticTest.java
src/test/java/org/apache/commons/jexl3/IssuesTest.java
> Map access operator does not work if key name clashes with map property name
>
>
> Key: JEXL-171
> URL: https://issues.apache.org/jira/browse/JEXL-171
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Critical
> Fix For: 3.0
>
>
> The following example returns *false*, according to documentation should
> return *2*.
> i = new ("java.util.HashMap"); i.a = 1; i["empty"] = 2; i["empty"]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (JEXL-171) Map access operator does not work if key name clashes with map property name
[
https://issues.apache.org/jira/browse/JEXL-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-171:
> Map access operator does not work if key name clashes with map property name
>
>
> Key: JEXL-171
> URL: https://issues.apache.org/jira/browse/JEXL-171
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Critical
> Fix For: 3.0
>
>
> The following example returns *false*, according to documentation should
> return *2*.
> i = new ("java.util.HashMap"); i.a = 1; i["empty"] = 2; i["empty"]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-178) Contention on functions can be reduced
[ https://issues.apache.org/jira/browse/JXPATH-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14650369#comment-14650369 ] Michele Vivoda commented on JXPATH-178: --- Hi, do you have any test that shows the improvement ? I would be curious to see if things get better with 2 maps: one not synchronized for statically initialized classes and interfaces (eg: registerAtomicClass), that does not change, and one synchronized for those registered later. The ideal would be to register statically all the needed classes in addition to those initialized at begin in jxpath code, may be with some property file.. so that is possible to use a map that does not change and does not need to be synchronized. For you changes, I believe JXPath is JDK4 where java.util.concurrent is not available. > Contention on functions can be reduced > -- > > Key: JXPATH-178 > URL: https://issues.apache.org/jira/browse/JXPATH-178 > Project: Commons JXPath > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Rico Neubauer >Priority: Minor > Labels: multithreaded > > Several series of thread dumps showed us that some avoidable synchronization > in jxpath causes plenty of blocked threads waiting on the sync block under > heavy load. > Using concurrent map makes the things better. > See this for a proposed fix: > https://github.com/seeburger-ag/commons-jxpath/commit/eeb7f30f761a6a89e03c2c1421c09968412659af.diff -- This message was sent by Atlassian JIRA (v6.3.4#6332)
