Axis Fault - HttpErrorCode:301 - Moved Permanently - axis

I have an old webservice application that always worked well. Suddenly, it stopped working and returns this error. I neither develop applications anymore, for years. I'm out of date.
Can anybody help me to solve this?
AxisFault
faultCode: {http://xml.apache.org/axis/}HTTP
faultSubcode:
faultString: (301)Moved Permanently
faultActor:
faultNode:
faultDetail:
{}:return code: 301
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
{http://xml.apache.org/axis/}HttpErrorCode:301
(301)Moved Permanently
at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:744)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at MRCS.ServiceANASoapStub.dadosHidrometeorologicos(ServiceANASoapStub.java:631)
at MRCS.ServiceANASoapProxy.dadosHidrometeorologicos(ServiceANASoapProxy.java:50)
at persistence.ConsultaPersisteTelemetrica._getDadosWebService(ConsultaPersisteTelemetrica.java:174)
at persistence.ConsultaPersisteTelemetrica._persisteTelemetrica(ConsultaPersisteTelemetrica.java:100)
at persistence.ConsultaPersisteTelemetrica.execute(ConsultaPersisteTelemetrica.java:42)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)

You could intercept such HTTP 301 codes and follow the redirects in your code. However, since you're no longer developing, the easiest way to fix this is to change the URL from http://xml.apache.org/axis/ to the new one that it redirects to, which is http://axis.apache.org/axis/.

Related

Can't install postsharp 4.2.25 to Visual Studio 2015

I'm taking an old branch which was using postshare 4.2.25
When I try to build the solution, I've a popup asking to install postsharp. I don't know why, because the solution use nuget package.
Also, this specific version isn't available on their site. But anyway, luckily we stored the package and so I can start the installation
But the problem is that the installation freeze for a long time (around 2 min) when I click next on this step:
After this freeze I've this error in red (which could be translated by: "Operation timeout"):
Any idea ?
I may try another version, but here I need to quickly patch an old version and updating postsharp version is not something you want to do in a patch...
Thank you
EDIT 1
I've see that the installer make a call, and this call never reply
The content of this call is:
POST http://visualstudiogallery.msdn.microsoft.com/services/Release4.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Host: visualstudiogallery.msdn.microsoft.com
Content-Length: 885
Expect: 100-continue
Connection: Keep-Alive
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://tempuri.org/IReleaseService4/Search</a:Action>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">http://visualstudiogallery.msdn.microsoft.com/services/Release4.svc</a:To>
</s:Header>
<s:Body>
<Search xmlns="http://tempuri.org/">
<searchText>nuget</searchText>
<whereClause>((Project.Metadata['SupportedVSEditions'] LIKE '%14.0,IntegratedShell;%') OR (Project.Metadata['SupportedVSEditions'] LIKE '%14.0,Pro;%'))</whereClause>
<orderByClause>Project.Metadata['Ranking'] desc</orderByClause>
<locale>1033</locale>
<skip>0</skip>
<take>25</take>
</Search>
</s:Body>
</s:Envelope>

Kubernetes services communication by REST: Stream ended unexpectedly

There are two services deployed into Kubernetes cluster. Service_1 exposes REST API, and one part of it is the method for file content uploading, so POST request with "Content-Type: multipart/form-data" is used.
The sample of real request, which is sending from Service_2 is:
Request DefaultFullHttpRequest(decodeResult: success, version: HTTP/1.1,
content: UnpooledHeapByteBuf(freed))
POST /engine-rest/deployment/create HTTP/1.1
Accept: application/json
User-Agent: process
Content-Type: multipart/form-data; boundary=28319d96a8c54b529aa9159ad75edef9
Content-Length: 4028
Host: service.cluster.ip:8080
The request cannot be processed and failed with an exception:
30-Mar-2017 18:17:29.623 WARNING [http-nio-8080-exec-2] org.camunda.bpm.engine.rest.exception.RestExceptionHandler.toResponse org.camunda.bpm.engine.rest.exception.RestException: multipart/form-data cannot be processed
at org.camunda.bpm.engine.rest.mapper.MultipartPayloadProvider.parseRequest(MultipartPayloadProvider.java:93)
at org.camunda.bpm.engine.rest.mapper.MultipartPayloadProvider.readFrom(MultipartPayloadProvider.java:71)
at org.camunda.bpm.engine.rest.mapper.MultipartPayloadProvider.readFrom(MultipartPayloadProvider.java:49)
at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:105)
at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:63)
at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108)
at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:169)
at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)
at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257)
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222)
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
at org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:169)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:212)
at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:59)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.camunda.bpm.engine.rest.filter.CacheControlFilter.doFilter(CacheControlFilter.java:41)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:617)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly
at org.apache.commons.fileupload.MultipartStream.readHeaders(MultipartStream.java:538)
at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:999)
at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:965)
at org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
at org.camunda.bpm.engine.rest.mapper.MultipartPayloadProvider.parseRequest(MultipartPayloadProvider.java:87)
... 38 more
What might be the reason of this error? I understand that the question doesn't have the direct answer, but I hope someone is able point me into the right way for additional investigation.
P.S. GET type requests of this API work fine.
Sorted out! If someone is interested or acccidentaly faced the exatly same problem, the root cause was in CLRF, which are required for multi-part requests, when we were using System.lineSeparator() and thus it hadn't worked under Linux. Yeah, so simple.

.NET AdaptivePayment SDK: PaymentDetails() is throwing a ConnectionException (404)

I am calling the AdaptivePaymentService.PaymentDetails() to get the payment details for a payment, and it is throwing a ConnectionException indicating 404. In order to debug the issue, I downloaded the source for the AdaptivePayment SDK as well as the Core SDK and stepped through the code, specifically, right where the HttpRequest is executed in Paypal.HttpConnection.Execute().
It appears as if all configuration variables are being read from the web.config:
The address in the underlying httpRequest looks correct:
The payload looks correct:
However, a WebException is thrown with the following response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /cgi-bin/ppapi was not found on this server.</p>
<p>Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.</p>
<hr>
<address>Apache Server at api.sandbox.paypal.com Port 443</address>
</body></html>
Any help would be greatly appreciated.
Since you have configured both ClientId/Secret and 3-token credentials (API username, password, signature) in your configuration, the endpoint has been detected incorrectly, giving the REST API higher preference. Please remove the client id / secret configuration and you should see the endpoint set correctly to https://svcs.sandbox.paypal.com/AdaptivePayments/PaymentDetails

Facebook gives me a "URL requested a HTTP redirect, but it could not be followed." but the browser has no issue following it, how can I fix that?

My URL is http://citynomads.com which redirects to http://www.citnomads.com and the browser follows the redirect perfectly well, but Facebooks linter is telling me it can't follow the link. I can't see why it's having an issue with this:
$ curl -i citynomads.com
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.0.8
Date: Sat, 28 Apr 2012 16:12:38 GMT
Content-Type: text/html
Content-Length: 160
Connection: keep-alive
Location: http://www.citynomads.com/
<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.0.8</center>
</body>
</html>
Linter: https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fcitynomads.com
How can I rectify that?
I think this is a FB linter bug. Your given linter link now works (has some other bizarre warnings, but not a failed redirect...)
This happened to me too, but posting the same url to facebook does generate a proper preview, so i'm guessing here...
Wouldn't be their first bug, nor the last...
HTH

SOAP Service: Missing WS-Addressing header

I have a Netbeans SOAP service I can deploy with no issues and a Silverlight client.
When I call the service from Silverlight, I get (in silverlight):
new DiscourseParserWSClient created;
event handler added;
service called; Service State is: Open
http://localhost:8080/DiscourseParserWS/DiscourseParserWSService
An exception occurred during the operation, making the result invalid.
The remote server returned an error: NotFound.
After the client calls the service, GlassFish v3 Domain responds with the following problem I fail to decipher:
WARNING: A required header representing a Message Addressing Property is not present, Problem header:{http://www.w3.org/2005/08/addressing}Action
com.sun.xml.ws.addressing.model.MissingAddressingHeaderException: Missing WS-Addressing header: "{http://www.w3.org/2005/08/addressing}Action"
at com.sun.xml.ws.addressing.WsaTube.checkCardinality(WsaTube.java:235)
at com.sun.xml.ws.addressing.WsaTube.checkMessageAddressingProperties(WsaTube.java:183)
at com.sun.xml.ws.addressing.WsaServerTube.checkMessageAddressingProperties(WsaServerTube.java:281)
at com.sun.xml.ws.addressing.WsaTube.validateInboundHeaders(WsaTube.java:140)
at com.sun.xml.ws.addressing.WsaServerTube.processRequest(WsaServerTube.java:147)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:112)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:195)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:127)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:295)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:515)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:285)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:143)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:147)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
I'm using Metro 2.1 and after quite some googling I suspect the problem might have something to do with it...
I can see the service's wsdl so I believe it can't be an implementation problem. But that warning's stack goes down to the Thread class o.O?
public void run() {
if (target != null) {
target.run(); // <-- to this line to be exact
}
}
Please help shed some light; I already have a couple of eclipse soap services working with this client, but I don't have experience with Netbeans, GlassFish and Metro and can't figure out what's causing this...
Don't know whether or not it is too late, but it helped me sometimes to add the
#Addressing(enabled=true,
required=false)
to the WebService (class annotation). Then the exception usually disappears.
For some more information about the addressing stuff you can refer to 1.
I was receiving the same WARNING and thought this might help someone else.
If you're using the "Reliable Message Delivery" option in Netbeans visual web service designer then you may get this warning.
If you don't require the "Reliable Message Delivery" you can simply turn it off.
I was facing this issue today and the problem was resolved by using the Action attribute on the soap header. I have confirmed this using SoapUI.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mal="http://example.com">
<soapenv:Header>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:2c7ea154-668e-4c8b-abaa-8b119f91b8dd</MessageID>
<Action xmlns="http://www.w3.org/2005/08/addressing">http://example.com/input</Action>
</soapenv:Header>
<soapenv:Body>
......
</soapenv:Body>
</soapenv:Envelope>
If we arent passing the Action attribute than we get error message:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<FaultDetail xmlns="http://www.w3.org/2005/08/addressing">
<ProblemHeaderQName>{http://www.w3.org/2005/08/addressing}Action</ProblemHeaderQName>
</FaultDetail>
</S:Header>
<S:Body>
<SOAP-ENV:Fault xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode xmlns:wsa="http://www.w3.org/2005/08/addressing">wsa:MessageAddressingHeaderRequired</faultcode>
<faultstring>A required header representing a Message Addressing Property is not present</faultstring>
</SOAP-ENV:Fault>
</S:Body>
</S:Envelope>
The value of Action header is determined from #Action on the webmethod.
#Action(input = "http://example.com/input", output = "http://example.com/output")