When trying to post a RESTful Service via docker-client to my private docker registry i get that error. The confusing thing about that is that the input stream changes itself as you can see here. Its made somewhere in the background of jersey but i cannot find the cause for it. I guess the problem occurs somewhere inside the jersey logic
Method
public static Service initService(String imageId) {
final com.spotify.docker.client.DockerClient docker = new DefaultDockerClient(
"http://10.###.###.143:2375");
String s = null;
try {
s = ("10.###.###.143:5000/user/ipatest&tag=latest");
docker.pull(s);
System.out.println(docker.toString());
} catch (DockerException | InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Exception
com.spotify.docker.client.DockerRequestException: Request error: POST http://10.###.###.143:2375/v1.12/images/create?fromImage=10.###.###.143%3A5000%2Fuser%2Fipatest%26tag%3Dlatest: 500
at com.spotify.docker.client.DefaultDockerClient.propagate(DefaultDockerClient.java:563)
at com.spotify.docker.client.DefaultDockerClient.request(DefaultDockerClient.java:544)
at com.spotify.docker.client.DefaultDockerClient.pull(DefaultDockerClient.java:345)
at com.spotify.docker.client.DefaultDockerClient.pull(DefaultDockerClient.java:329)
at de.fhg.ipa.vfk.eapps.commoniaas.docker.DockerServiceMgmt.initService(DockerServiceMgmt.java:43)
at de.fhg.ipa.vfk.eapps.commoniaas.docker.DockerServiceMgmt.main(DockerServiceMgmt.java:163)
Caused by: com.sun.jersey.api.client.UniformInterfaceException: POST http://10.###.###.143:2375/v1.12/images/create?fromImage=10.###.###.143%3A5000%2Fuser%2Fipatest%26tag%3Dlatest returned a response status of 500 Internal Server Error
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:688)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.method(WebResource.java:623)
at com.spotify.docker.client.DefaultDockerClient.request(DefaultDockerClient.java:540)
... 4 more
It must have something to do with queryParams(String params) which belongs to WebResource (jersey)
The image name you're passing to pull isn't valid. The format for an image name is name:tag. Do this instead:
docker.pull("10.###.###.143:5000/user/ipatest:latest");
Alternatively, you can ommit the :latest, since it is implied when no other tag is specified.
Related
I am not able to print the response from a Soap Webservice.
Seen few solutions by editing the generated stub code. But I cant edit the generated code as it gets restored to original form on every build. Looking for a solution where I can get the solution printed without change in generated code.
I am consuming the SOAP service from a Spring Boot microservice.
ServiceContext serviceConxt = omsSchedulingService._getServiceClient().getServiceContext();
OperationContext operationContext = serviceConxt.getLastOperationContext();
MessageContext inMessageContext = operationContext.getMessageContext("Out");
log.info(inMessageContext.getEnvelope().toString());
You can add a message handler for the soap message.
Then once you intercept the message with the handler, you can print out the response.
You will need to add the handler to the handler chain, depending on your project you can do that programatically or with config.
final class MyMessageHandler implements SOAPHandler<SOAPMessageContext>{
#Override
public void close(MessageContext context) {
handle(context);
}
private boolean handle(MessageContext context) {
if (context != null) {
try {
Object httpResponseCodeObj = context.get(SOAPMessageContext.HTTP_RESPONSE_CODE);
if (httpResponseCodeObj instanceof Integer)
httpResponseCode = ((Integer) httpResponseCodeObj).intValue();
if (context instanceof SOAPMessageContext) {
SOAPMessage message = ((SOAPMessageContext) context).getMessage();
ByteArrayOutputStream byteOut = new ByteArrayOutputStream(512);
message.writeTo(byteOut);
String messageStr = byteOut.toString(getCharacterEncoding(message));
boolean outbound = Boolean.TRUE.equals(context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY));
Logger.info(loggingPrefix, outbound ? "SOAP request: " : "SOAP response: ", replaceNewLines(messageStr));
}
} catch (SOAPException e) {
Logger.error(e, loggingPrefix, "SOAPException: ", e.getMessage(), NEWLINE);
} catch (IOException e) {
Logger.error(e, loggingPrefix, "IOException: ", e.getMessage(), NEWLINE);
}
}
return true;
}
}
If you donĀ“t want to implement an interceptor the easiest way is to use the logging via vm arguments:
JAVA_OPTS=-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog -Dorg.apache.commons.logging.simplelog.showdatetime=true -Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug -Dorg.apache.commons.logging.simplelog.log.org.apache.commons.httpclient=debug
This way you should see the logging of your request / response with headers in console.
First you can get AxisConfiguration from client stub.
AxisConfiguration axisConf = stub._getServiceClient().getAxisConfiguration();
Processing incoming and outgoing messages is divided into phases. There is a list of phases (a flow) which is processed when everything works correctly (without errors) and also another for situations when some fault occurs e.g. when an exception is thrown during message processing. Every flow maybe incoming or outgoing so there are 4 flows altogether.
List<Phase> phasesIn = axisConf.getInFlowPhases(); // normal incoming communication i.e. response from webservice
List<Phase> phasesOut = axisConf.getOutFlowPhases(); // normal outgoing communication
List<Phase> phasesFaultIn = axisConf.getInFaultFlowPhases(); // faulty incoming communication e.g. when an exception occurs during message processing
List<Phase> phasesFaultOut = axisConf.getOutFaultFlowPhases(); // faulty outgoing communication
Some but not all phase names are defined in org.apache.axis2.phaseresolver.PhaseMetadata.
For example "Security" phase processed in Rampart module (module for Web Service Security) won't be found in PhaseMetadata.
You can add a handler to every phase, e.g.
for (Phase p : phasesOut) {
if (PhaseMetadata.PHASE_TRANSPORT_OUT.equals(p.getName())) {
p.addHandler(new MessageContentLoggerHandler());
}
}
Handler is a class which extends org.apache.axis2.handlers.AbstractHandler.
You just have to implement
public InvocationResponse invoke(MessageContext msgContext).
There you have access to MessageContext. Of course, you can get whole SOAP envelope like this:
msgContext.getEnvelope().toString()
and for example print it to your logs or save as a separate file.
Remember to put
return InvocationResponse.CONTINUE;
at the end of invoke method for a situation when handler processes the message successfully. Otherwise processing stops in this handler and a whole process won't get to any another phase.
If you need to see whole message with WSS headers, you can add your own phase. For example this adds your custom phase as the last in processing of outgoing message (so also after Rampart's security phase)
Phase phase = new Phase("SomePhase");
phase.addHandler(new SomeCustomHandler());
axisConf.getOutFlowPhases().add(phase);
Of course logging (and exposing in any other way) security headers in production environment is a very bad idea. Do it only for debugging purposes in some test environment.
It shows the error:
Invalid response from server: HTTP/1.1 429 Too Many Requests
I use a button to get the name what I want to search:
if (v.getId() == R.id.find) {
String keyword = name.getText().toString();
new UpdateSearch().execute(keyword);
find.setEnabled(false);
}
The following is the use of GeocoderNominatim in a AsyncTask:
public class UpdateSearch extends AsyncTask<String, Void, List<Address>> {
#Override
protected List<Address> doInBackground(String... params) {
// TODO Auto-generated method stub
GeocoderNominatim coderNominatim = new GeocoderNominatim(
MainActivity.this);
List<Address> geoResults = null ;
try {
geoResults = coderNominatim.getFromLocationName(params[0], 3);
Log.d("aaaaaaaaaaaaaa",String.valueOf(coderNominatim));
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return geoResults;
}
#Override
protected void onPostExecute(List<Address> result) {...
And I got errors :
09-13 15:04:39.352: D/BONUSPACK(547):
GeocoderNominatim::getFromLocationName:http://nominatim.openstreetmap.org/search?format=json&accept-language=zh&addressdetails=1&limit=3&q=%E6%95%85%E5%AE%AB
09-13 15:04:39.355: W/System(547): ClassLoader referenced unknown path: /system/framework/tcmclient.jar
09-13 15:04:40.918: E/BONUSPACK(547): Invalid response from server: HTTP/1.1 429 Too Many Requests
Some days ago, I can use the bonuspack and I got what I want. But recently the bonuspack becomes worse.
HTTP/1.1 429 Too Many Requests means you are performing too many requests from your IP address.
The Nominatim instance you are using is run by volunteers on donated resources. Please read the usage policy, especially the part about the number of requests per second.
If you need to perform more requests then either switch to a different Nominatim instance or install your own Nominatim server.
from nominatim policies
Provide a valid HTTP Referer or User-Agent identifying the application (stock User-Agents as set by http libraries will not do).
you have to setup an app specific useragent
String MY_USERAGENT = "com.beview.mygeoapp";
GeocoderNominatim coderNominatim = new GeocoderNominatim(
MainActivity.this, MY_USERAGENT);
I have been trying to put together some code that will- among other things - upload files to a Sharepoint site that uses NTLM authentication. Earlier versions of the code were single threaded, and worked perfectly. They uploaded the file exactly as expected without the slightest issue. However, I eventually tried to multi-thread this application, so that it could upload many files at once, while still going about the rest of its business.
However when I tried to multithread the code, it fails every single time, throwing an IndexOutOfBoundsException. This is singularly unhelpful to me in diagnosing the actual cause of the problem.
In case you are wondering, if I change out the CachedThreadExecutor for a SingleThreadExecutor - forcing the code bask to a single-threaded state - it once again works fine.
Creating the executor and connection manager, and constructing threads:
class OrderProcessor implements Runnable {
//Other variables for object
private final ExecutorService executorService = Executors
.newCachedThreadPool();
// .newSingleThreadExecutor();
private HttpClientConnectionManager conManager;
private void setup() {
//always called before execution of anything else in object
conManager = new PoolingHttpClientConnectionManager();
}
//lots of other code
}
The actual code for submitting the threads is complicated, so this version is somewhat simplified, but gets the point across.
for(Request request : requests){
//Do other stuff
simpleSubmitFile(request);
//Do other stuff
}
Here is the simplified file submission method
public Future<Boolean> simpleSubmitFile(Request request){
transferer = new SharePointTransferer(extractionRequest, conManager);
Future<Boolean> future = executorService.submit(transferer);
return future;
}
SharePointTransferer code
//actual values scrubbed
private final String USERNAME = "";
private final String PASSWORD = "";
private final String DOMAIN = "";
private final File sourceFile;
private final String destinationAddress;
private final CloseableHttpClient client;
public SharePointTransferer(final Request extractionRequest, HttpClientConnectionManager conManager) {
super(extractionRequest);
this.sourceFile = this.extractionRequest.getFile();
this.destinationAddress = this.extractionRequest.getDestinationAddress();
this.client = HttpClients.custom()
.setConnectionManager(conManager).build();
}
public Boolean call() throws Exception {
String httpAddress = correctSharePointAddress(destinationAddress);
HttpPut put = new HttpPut(httpAddress + sourceFile.getName());
// construct basic request
put.setEntity(new FileEntity(sourceFile));
HttpClientContext context = HttpClientContext.create();
// set credentials for the SharePoint login
CredentialsProvider credProvider = new BasicCredentialsProvider();
credProvider.setCredentials(AuthScope.ANY, new NTCredentials(USERNAME,
PASSWORD, "", DOMAIN));
context.setCredentialsProvider(credProvider);
// execute request
try {
HttpResponse response = client.execute(put, context);
logger.info("response code was: "
+ response.getStatusLine().getStatusCode());
if (response.getStatusLine().getStatusCode() != 201) {
throw new FileTransferException(
"Could not upload file. Http response code 201 expected."
+ "\nActual status code: "
+ response.getStatusLine().getStatusCode());
}
} catch (ClientProtocolException e) {
throw new FileTransferException(
"Exception Occurred while Transferring file "
+ sourceFile.getName(), e);
} catch (IOException e) {
throw new FileTransferException(
"Exception Occurred while Transferring file "
+ sourceFile.getName(), e);
}finally{
logger.info("deleting source file: " + sourceFile.getName());
sourceFile.delete();
client.close();
}
logger.info("successfully transfered file: "+sourceFile.getName());
return true;
}
If I submit multiple files it throws essentially the exact same exception for all of the files. The trace is below
Exception Stack Trace
2015-04-16 11:49:26 ERROR OrderProcessor:224 - error processing file: FILE_NAME_SCRUBBED
PACKAGE_SCRUBBED.FileProcessingException: Could not process file: FILE_NAME_SCRUBBED
at PACKAGE_SCRUBBED.OrderProcessor.finishProcessingOrder(OrderProcessor.java:223)
at PACKAGE_SCRUBBED.OrderProcessor.run(OrderProcessor.java:124)
at PACKAGE_SCRUBBED.FileTransferDaemon.process(FileTransferDaemon.java:48)
at PACKAGE_SCRUBBED.FileTransferDaemon.start(FileTransferDaemon.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
Caused by: java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: 41
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at PACKAGE_SCRUBBED.OrderProcessor.finishProcessingOrder(OrderProcessor.java:208)
... 8 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 41
at org.apache.http.impl.auth.NTLMEngineImpl$NTLMMessage.addByte(NTLMEngineImpl.java:924)
at org.apache.http.impl.auth.NTLMEngineImpl$NTLMMessage.addUShort(NTLMEngineImpl.java:946)
at org.apache.http.impl.auth.NTLMEngineImpl$Type1Message.getResponse(NTLMEngineImpl.java:1052)
at org.apache.http.impl.auth.NTLMEngineImpl.getType1Message(NTLMEngineImpl.java:148)
at org.apache.http.impl.auth.NTLMEngineImpl.generateType1Msg(NTLMEngineImpl.java:1641)
at org.apache.http.impl.auth.NTLMScheme.authenticate(NTLMScheme.java:139)
at org.apache.http.impl.auth.AuthSchemeBase.authenticate(AuthSchemeBase.java:138)
at org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
at org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:202)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:262)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at PACKAGE_SCRUBBED.SharePointTransferer.call(SharePointTransferer.java:74)
at PACKAGE_SCRUBBED.SharePointTransferer.call(SharePointTransferer.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
If anyone can figure out what is causing this problem, I would greatly appreciate it.
EDIT: I managed to find a workaround that fixes the issue for me, but would still appreciate an explanation of exactly what is going on.
this is a bug, solved in httpclient version 4.5.2
http://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.5.x.txt
Release 4.5.2
Changelog:
[HTTPCLIENT-1715] NTLMEngineImpl#Type1Message not thread safe but declared as a constant. Contributed by Olivier Lafontaine , Gary Gregory
You can't reuse nor HttpClientContext neither NTLMScheme in a concurrent environment because they are both marked as #NotThreadSafe (see javadoc).
In my environment I got the same error, solved with something like:
synchronized(context) {
HttpResponse response = client.execute(put, context);
}
The authenticated context is reused, but one thread at time.
I eventually managed to solve this problem by setting the number of connections per route to 1, as below.
conManager.setDefaultMaxPerRoute(1);
I'm still not exactly sure why the problem occured, or what the proper way to fix this is, but this solution worked for me.
I need a little help understanding the basics of Jsoup. The following code works but I'm wondering if the connection needs to be closed somehow. Can't find anything on the Jsoup website about it. If the application remains untouched after the do in background method executes I get a message in log cat every five minutes or so saying "request time failed: java.net.SocketException: Address family not supported by protocol". So I want to make sure I'm not unnecessarily consuming data. Thank you.
protected String doInBackground(String... params) {
// TODO Auto-generated method stub
try {
// connect to web page based on user input
Document doc = Jsoup.connect(routeURL).get();
// select relevant page elements
Elements fareStageNumbers = doc.getElementsByClass("fare_stages_inner_table");
// test printing out fare stage numbers
for(Element div : fareStageNumbers){
Log.v(TAG, div.text());
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return null;
}
logcat message:
01-12 20:58:28.755: D/SntpClient(78): request time failed: java.net.SocketException: Address family not supported by protocol
01-12 21:03:28.765: D/SntpClient(78): request time failed: java.net.SocketException: Address family not supported by protocol
01-12 21:08:28.775: D/SntpClient(78): request time failed: java.net.SocketException: Address family not supported by protocol
Jsoup closes the connection by its own, after the request is done:
// from 'org.jsoup.helper.HttpConnection' class
static HttpConnection.Response execute(Connection.Request req, HttpConnection.Response previousResponse) throws IOException {
// ...
HttpURLConnection conn = createConnection(req);
HttpConnection.Response res;
try {
// ...
} finally {
// per Java's documentation, this is not necessary, and precludes keepalives. However in practise,
// connection errors will not be released quickly enough and can cause a too many open files error.
conn.disconnect();
}
// ...
}
Exception: Does your url contain the protocol (the url start with eg. http://)?
I'm having a problem with a WCF Service and Java Client, I will try to give as much information as i can, thanks for your time.
The Endpoint of the server is BasicHttpBinding, I tried hosting the server as a Windows Service and in IIS but nothing changed.
The weird thing is that the Client works great if I use a simple class, in the moment I switch the class to an JApplet I get the problem mentioned.
I'm using Eclipse as an IDE, I tried Axis and Metro to generate the stub with the same bad results.
Here is an example of the Java class where everything is working
public class TestSoaMetro {
public String TestMethod(){
String result = null;
IDigitalSignatureService aa = new DigitalSignatureService().getBasicHttpBindingEndpoint();
try {
result = aa.getData("1", "id002962");
} catch (IDigitalSignatureServiceGetDataArgumentExceptionFaultFaultMessage e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IDigitalSignatureServiceGetDataInvalidOperationExceptionFaultFaultMessage e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return result;
}
}
Here is the example of the JApplet where I get the error:
public class TestSoaMetroApplet extends JApplet {
public void init() {
Container content = getContentPane();
content.setBackground(Color.white);
content.setLayout(new FlowLayout());
String result= this.TestMethod();
JLabel label = new JLabel(result);
content.add(label);
}
public String TestMethod(){
String result = null;
IDigitalSignatureService aa = null;
try {
aa = new DigitalSignatureService().getBasicHttpBindingEndpoint();
result= aa.getData("1", "id002962");
} catch (IDigitalSignatureServiceGetDataArgumentExceptionFaultFaultMessage e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IDigitalSignatureServiceGetDataInvalidOperationExceptionFaultFaultMessage e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return result;
}
}
In the moment the Applet loads I get the error, is the exact same call so I don't understand why I get the exception using the Applet. I Also tried to call this from a Silverlight client and I was getting a security exception, this is where I found out about clientaccesspolicy.xml and crossdomain.xml, I added clientaccesspolicy.xml to the service and the Silverlight Client works great, so I decided to try crossdomain.xml and nothing, the Applet still does not work.
I will put the stack trace at the end, thanks all for your time.
Juan Zamudio
javax.xml.ws.WebServiceException: org.apache.axis2.AxisFault: Transport error: 405 Error: Method not allowed
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:559)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:118)
at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:82)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:317)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:159)
at $Proxy12.getData(Unknown Source)
at TestSoaMetroApplet.TestMethod(TestSoaMetroApplet.java:28)
at TestSoaMetroApplet.init(TestSoaMetroApplet.java:19)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.axis2.AxisFault: Transport error: 405 Error: Method not allowed
at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:295)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:190)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:389)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:222)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:435)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:402)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:554)
... 9 more
The exception is obviously caused by an HTTP 405 error, so it is the server, which decides that the client is not allowed to invoke the method. If it is an applet or a standalone Java application should not really matter. Is the applet and the standalone application perhaps accessing the server from different IPs and the server is configured to allow access from the IP used by the standalone app, but denying access from the IP used by the applet?