Using apache commons httpClient PutMethod to upload a doc to sharepoint 2010 as it was a large it is taking time and after sometime i am throwing by an exception.
Socket Error: Connection Reset by peer : socket write error
as peer means share-point is closing socket or socket just failing to write where is the error, can fix for this issue from java side.
Update:
After troubleshooting the class its working has standalone java class, but it is failing when it is running in Tomcat server. I think some configuration of tomcat server will fix this issue.
My understanding the tomcat server is a web server deals with http protocol and my java class is implementation of apache HttpClient 3.1 so this java class is works as individual class and failing in tomcat server means tomcat is overriding my httpclient params which is causing this issue
You will find below link use full in your case.I resolved same issue by reading below details.
http://jce.iaik.tugraz.at/sic/Products/Communication-Messaging-Security/iSaSiLk/documentation/Secure-Renegotiation
Related
I'm having difficulty using Fiddler to diagnose a problem in a Java application to connect to Microsoft Graph's API. Here's my basic environment:
JDK: 1.8.0_131
Apache HttpClient: 4.4
Fiddler: 4.6
The endpoint I'm trying to reach is https://login.microsoftonline.com/common/oauth2/authorize The problem I have is that the traffic is not captured by Fiddler.
I've tried various things as suggested by Googling for this problem, but have not got it to work. In my application, I set the proxy settings as follows:
httpClientBuilder.setProxy(new HttpHost(proxyServer, proxyPort, proxyScheme));
httpClientBuilder.build();
If I use ("127.0.0.1", 8888, "https"): then the error that I see is:
Unrecognized SSL message, plaintext connection?
If I use
("127.0.0.1", 8888, "http"): then the error that I see is: I/O
exception (org.apache.http.conn.UnsupportedSchemeException) caught
when processing request to
{tls}->http://127.0.0.1:8888->https://login.microsoftonline.com:443:
http protocol is not supported
I've tried other things (for example "localhost", "localhost.", and so on as suggested, and setting: -Djsse.enableSNIExtension=false), but so far no luck. Hopefully I am missing something obvious! Thanks for any help.
It turns out that the second configuration for the proxy is the correct one to use (using "http"), but what I had forgotten was that I was setting a ConnectionSocketFactoryRegistry in my HttpClientBuilder. I had not registered a ConnectionSocketFactory for "http" and this caused the second configuration to fail. I added this to the HttpClientBuilder, and now I can see traffic being captured by Fiddler:
connectionSocketFactoryRegistryBuilder.register("http", new PlainConnectionSocketFactory());
I was using Jersey 2.25 client with Jackson, I configured everything correctly in Jersey, it worked normally on my development machine when I ran it in a test class, but Jersey client could never connect to a certain host that we have when deployed on our STG environment and always throws a read timeout exception.
I also know that the problem is not in our environment because I can connect using curl
But when switched to HTTPClient it worked normally.
This is how we created our Jersey Client:
Client client = ClientBuilder.newBuilder()
.register(JacksonFeature.class)
.property(ClientProperties.CONNECT_TIMEOUT,5000)
.property(ClientProperties.READ_TIMEOUT,15000)
.build();
The only difference here is the flow of the app, and also the major change that happens in the flow that could affect the connection is that somewhere before calling the Jersey client another class sets a proxy in the system config:
System.setProperty("http.proxyHost",strProxyHost);
System.setProperty("http.proxyPort",strProxyPort);
System.setProperty("https.proxyHost",strProxyHost);
System.setProperty("https.proxyPort",strProxyPort);
However we can establish a connection normally using HTTPClient:
HttpConnectionManagerParams params = new HttpConnectionManagerParams();
params.setConnectionTimeout(5000);
params.setSoTimeout(10000);
HttpConnectionManager manager = new SimpleHttpConnectionManager();
manager.setParams(params);
HttpClient httpClient = new HttpClient(manager);
We are using HTTPClient 3 because part of this app is legacy and we cannot update the version, but it works normally.
What could be causing this connection problem with Jersey? is there something global that Jersey reads when it's trying to connect?
Jersey by default uses HttpURLConnection and HttpURLConnection uses following global settings for proxy configuration -
System.setProperty("http.proxyHost",strProxyHost);
System.setProperty("http.proxyPort",strProxyPort);
System.setProperty("https.proxyHost",strProxyHost);
System.setProperty("https.proxyPort",strProxyPort);
It means if these system variables are set, Jersey will send all the requests through this configured proxy. Check Details here
However, Apache HttpClient does not follow these settings. For using proxy in Apache HttpClient, you have to use HostConfiguration class. Check details here
So, now to your problem, It looks that your STG environment is not able to connect to specified proxy but able to connect with the service directly.
So, while using Jersey, client is not able to connect to proxy and hence ReadTimeoutException is occurring. Since, you haven't configured HttpClient for using any proxy, it is able to connect with the service directly.
I'm consuming a web service in a java class standalone and it works fine.
I deployed that class as a part of a web-app in tomcat apache and it works fine.
Then, I deployed it in a glassfish server and I get this error:
WSS1601: Transport binding configured in policy but incoming message was not SSL enabled
I have several weeks stuck here. Seems like some glassfish setting doesn't accepts that my web-app uses a web service that works through HTTP (this is, and has to be the case).
The webservice client was made with the web service client wizard tool of netbeans (it uses wsimport-JAX-WS). More details on the error trace from the server:
com.sun.xml.wss.impl.XWSSecurityRuntimeException: WSS1601: Transport binding configured in policy but incoming message was not SSL enabled
at com.sun.xml.wss.impl.policy.verifier.MessagePolicyVerifier.verifyPolicy(MessagePolicyVerifier.java:125)
Has anybody else faced this issue?
Any help or ideas appreciated.
EDIT: I tried generating the stubs using the axis2 tool and it works great, so i'm sensing some kind of error in jax-ws when used in glassfish.
I guess you are trying to access the service enables with SSL. Try invoking the service with https also you have to install the valid SSL certificate in the client JDK.
The following link explain how to obtain and install a signed certificate :
https://docs.oracle.com/cd/E19798-01/821-1794/aeogl/index.html
Good luck :)
I have installed a ftp server locally. I have a web service running on my web server too. My client class send a byte stream to web service which needs to be uploaded in to a file server. Both web server and file server running locally. When I'm trying to connect to the file server an exception is thrown. It looks the exception is thrown while trying to connect.
FTPClient client = new FTPClient()
client.connect("ftp.127.0.0.1");
client.login("username", "password");
I'm using Apache commons net library for FTPClient. I want to know whether this is acceptable to access the local file server from local web server. If so, Is there anything wrong on my code to get connection ?
Exception I get is added below
java.net.UnknownHostException: ftp.127.0.0.1
If you think there is something wrong with your code, not with instance of your FTP Server, then I would recommend to write a test when you would mock FTP server:
Here you'll find a way to mock it:
http://mockftpserver.sourceforge.net/fakeftpserver-versus-stubftpserver.html
Instead of ftp.127.0.0.1
use 127.0.0.1.
We are trying to consume a Java Web Service hosted on Oracle WebLogic Server (implemented following JAX-WS specifications) from a C# WCF 4.0 Client.
The error codes thrown on Server Side Trace is
Error codes: 3001 3201 4008 4208 6408 Error code:3001
We are unable to figure out what these means ? It seems these are not documented. (We might be wrong or looking at a wrong place).