AEM servlet not render in publisher instance - ajax

I have followed this tutorial to create a form to submit data to SlingAllMethodsServlet . It works fine with the author instance. Once I published the page It shows the blank page in publisher instance.
I have installed the AEM 6.2 in ubuntu 14.04 machine. To create the above form I have used the templates & components. This is the error logs print when render the publisher instance.
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse sent. Response: 200 OK
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse ------------------------------------------------
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse Sending message to localhost:4503
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse >> GET /bin/receive?sling:authRequestLogin=1 HTTP/1.0
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse >> Action: Internal Poll
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse >> Path:
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse >> Handle:
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse --
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse << HTTP/1.1 200 OK
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse << Date: Wed, 10 Jun 2020 17:30:55 GMT
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse << X-Content-Type-Options: nosniff
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse << Content-Type: application/octet-stream
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse << Content-Length: 32
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse Message sent.
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse ------------------------------------------------
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse Reverse replication successful.
10.06.2020 23:00:55.463 *INFO* [sling-default-1297-com.day.cq.replication.impl.ReverseReplicator.2114] com.day.cq.replication.Agent.publish_reverse Fetched 0 contents from http://localhost:4503/bin/receive?sling:authRequestLogin=1 since null

So actually you expect us to read the referenced tutorial to find out what the expected result is here and then we should do some magic to guess what went wrong in your case and help you while you sit there and wait? Really? I mean, REALLY?
Let me tell you about a big AEM secret: There is a mysterious thing called "The allknowing error.log". Maybe you should have a look first and if you are worthy, it might tell you what the problem is...

Related

Feign Client: How to log the server name which the request was sent to?

I am using a Feign Client to call a REST endpoint with success, and have logging turned on to FULL. This is helpfully shows me the request sent and the response received. However, I cannot see which server the request was sent to. It only shows me that it was POSTed to http://foo-service which is the name of the service, not the name of the server.
How can I log which server name this request was sent to?
This is what I see in the logs:
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] ---> POST http://foo-service/some-endoint HTTP/1.1
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] Accept: application/json
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] Content-Type: application/json
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] Content-Length: 15
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar]
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] {"name":"John"}
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] ---> END HTTP (15-byte body)
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] <--- HTTP/1.1 200 (8ms)
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] Transfer-Encoding: chunked
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] X-Application-Context: fooService:9006
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] Date: Tue, 10 Oct 2017 09:25:36 GMT
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] Content-Type: application/json;charset=UTF-8
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar]
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] {"result":"Hello John"}
c.l.l.r.service.FooFeignClient : [FooFeignClient#bar] <--- END HTTP (23-byte body)
To turn on logging, I declare this bean:
#Bean
public feign.Logger.Level feignLoggerLevel() {
return Logger.Level.FULL;
}
We are using spring-cloud-netflix-core:1.1.0.M4
You will need to provide your own Logger to achieve this. The default Logger is very simple and logs the host before the request is sent. When using Ribbon the information will be available with the Response. If you override the logAndRebufferResponse method, the response.url property will be the entire url submitted, including host name.
protected Response logAndRebufferResponse(
String configKey,
Level logLevel,
Response response,
long elapsedTime) throws IOException {
/* ask the response for the request and log the uri */
log(response.request.url());
}
Enable logging via logback and set log level of debug or these classes
<logger name="com.netflix.loadbalancer.BaseLoadBalancer" level="DEBUG"/>
<logger name="com.netflix.loadbalancer.LoadBalancerContext" level="DEBUG"/>
<logger name="com.netflix.loadbalancer.reactive.LoadBalancerCommand" level="DEBUG"/>
I can see where each request is going (server:port) and request failed on which server
DEBUG [ c.a.m.c.f.CommonProducerClient][72] - [CommonProducerClient#findAllEmployee] ---> GET http://COMMON-PRODUCER/allemployee HTTP/1.1
DEBUG [ c.n.loadbalancer.LoadBalancerContext][492] - COMMON-PRODUCER using LB returned Server: localhost:7001 for request http:///allemployee
DEBUG [ c.n.l.reactive.LoadBalancerCommand][314] - Got error java.net.ConnectException: Connection refused: connect when executed on server localhost:7001
DEBUG [ c.n.l.reactive.LoadBalancerCommand][314] - Got error java.net.ConnectException: Connection refused: connect when executed on server localhost:7001
DEBUG [ c.n.l.reactive.LoadBalancerCommand][314] - Got error java.net.ConnectException: Connection refused: connect when executed on server localhost:7001
DEBUG [ c.n.loadbalancer.LoadBalancerContext][492] - COMMON-PRODUCER using LB returned Server: localhost:7003 for request http:///allemployee
DEBUG [ c.a.m.c.f.CommonProducerClient][72] - [CommonProducerClient#findAllEmployee] <--- HTTP/1.1 200 (4010ms)
From Logs its clear, first request went to port 7001, connection refused there, second request goes to 7003, all good there.

CXF JAX-RS client always sends empty PUT requests in chunking mode regardles of AllowChunking setting

We perform PUT request to our party using CXF JAX-RS client. Request body is empty.
A simple request invocation leads to server response with code 411.
Response-Code: 411
"Content-Length is missing"
Our party's REST-server requires Content-Length HTTP-header to be set.
We switched chunking off according to note about chunking but this did not solve the problem. The REST-server still answers with 411 error.
Here is our conduit configuration from cxf.xml file
<http-conf:conduit name="{http://myhost.com/ChangePassword}WebClient.http-conduit">
<http-conf:client AllowChunking="false"/>
</http-conf:conduit>
Line in the log confirms that execution of our request bound to our conduit configuration:
DEBUG o.a.cxf.transport.http.HTTPConduit - Conduit '{http://myhost.com/ChangePassword}WebClient.http-conduit' has been configured for plain http.
Adding Content-Length header explicitly also did not help.
Invocation.Builder builder = ...
builder = builder.header(HttpHeaders.CONTENT_LENGTH, 0);
A CXF Client's log entry confirms header setting, however when we sniffed packets, we have surprisingly found that header setting has been completely ignored by CXF client. Content-Length header was not sent.
Here is the log. Content-Length header is present:
INFO o.a.c.i.LoggingOutInterceptor - Outbound Message
---------------------------
ID: 1
Address: http://myhost.com/ChangePassword?username=abc%40gmail.com&oldPassword=qwerty123&newPassword=321ytrewq
Http-Method: PUT
Content-Type: application/x-www-form-urlencoded
Headers: {Accept=[application/json], client_id=[abcdefg1234567890abcdefg12345678], Content-Length=[0], Content-Type=[application/x-www-form-urlencoded], Cache-Control=[no-cache], Connection=[Keep-Alive]}
--------------------------------------
DEBUG o.apache.cxf.transport.http.Headers - Accept: application/json
DEBUG o.apache.cxf.transport.http.Headers - client_id: abcdefg1234567890abcdefg12345678
DEBUG o.apache.cxf.transport.http.Headers - Content-Length: 0
DEBUG o.apache.cxf.transport.http.Headers - Content-Type: application/x-www-form-urlencoded
DEBUG o.apache.cxf.transport.http.Headers - Cache-Control: no-cache
DEBUG o.apache.cxf.transport.http.Headers - Connection: Keep-Alive
And here is an output of the packet sniffer. Content-Length header is not present:
PUT http://myhost.com/ChangePassword?username=abc%40gmail.com&oldPassword=qwerty123&newPassword=321ytrewq HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/json
client_id: abcdefg1234567890abcdefg12345678
Cache-Control: no-cache
User-Agent: Apache-CXF/3.1.8
Pragma: no-cache
Host: myhost.com
Proxy-Connection: keep-alive
Does anyone know how actually disable chunking?
Here is our code:
public static void main(String[] args)
{
String clientId = "abcdefg1234567890abcdefg12345678";
String uri = "http://myhost.com";
String user = "abc#gmail.com";
Client client = ClientBuilder.newBuilder().newClient();
WebTarget target = client.target(uri);
target = target.path("ChangePassword").queryParam("username", user).queryParam("oldPassword", "qwerty123").queryParam("newPassword", "321ytrewq");
Invocation.Builder builder = target.request("application/json").header("client_id", clientId).header(HttpHeaders.CONTENT_LENGTH, 0);
Response response = builder.put(Entity.form(new Form()));
String body = response.readEntity(String.class);
System.out.println(body);
}
Versions:
OS: Windows 7 Enterprise SP1
Arch: x86_64
Java: 1.7.0_80
CXF: 3.1.8
I had a very similar issue that I was not able to solve as you did by trying to turn off chunking.
What I ended up doing was setting the Content-Length to 1 and adding some white space " " as the body. For me it seemed that the proxy servers before the server application was rejected the request and by doing that got me past the proxy servers and the server was able to process the request as it was only operating based on the URL.

Savon 2.1.0 basic auth not functioning

I am trying to access a SOAP service which has the following charateristics:
1. WSDL is available without authentication
2. The service is accessible over https with basic_auth
3. According to the SOAP service, the "Authorization" header needs to be included in every request
Here is my code for construction the soap client:
#wsdl="https://example.com/table.do&WSDL"
#proxy="http://internal.proxy.com:8080"
#basic_auth=["user","pass"]
#headers={"Authorization" => "Basic"}
client = Savon.client do |globals|
globals.wsdl #wsdl
globals.proxy #proxy
globals.basic_auth #basic_auth
globals.headers #headers
end
Here is the client.globals.inspect:
#<Savon::GlobalOptions:0x0000000382c7a8 #options={:encoding=>"UTF-8",
:soap_version=>1, :namespaces=>{}, :logger=>#<Logger:0x0000000382c730 #progname=nil,
#level=0, #default_formatter=#<Logger::Formatter:0x0000000382c708
#datetime_format=nil>,
#formatter=nil, #logdev=#<Logger::LogDevice:0x0000000382c6b8 #shift_size=nil,
#shift_age=nil, #filename=nil, #dev=#<IO:<STDOUT>>,
#mutex=#<Logger::LogDevice::LogDeviceMutex:0x0000000382c690 #mon_owner=nil,
#mon_count=0, #mon_mutex=#<Mutex:0x0000000382c640>>>>, :log=>true, :filters=>[],
:pretty_print_xml=>false, :raise_errors=>true, :strip_namespaces=>true,
:convert_response_tags_to=>#<Proc:0x0000000382c5c8#/usr/local/rvm/gems/ruby-2.0.0-p0/gems/savon-2.1.0/lib/savon/options.rb:48 (lambda)>,
:wsdl=>"https://example.com/table.do&WSDL",
:proxy=>"http://internal.proxy.com:8080",
:basic_auth=>["user", "pass"],
:headers=>{"Authorization"=>"Basic"}}>
when i call:
client.call(:get, message: { sys_id: "67d2f77ed9377840c53fc6da9c094635" })
The service is returning:
DEBUG -- : HTTPI GET request to xseaddev.service-now.com (net_http)
INFO -- : SOAP request: https://xseaddev.service-now.com/change_task_list.do?displayvalue=all&SOAP
INFO -- : SOAPAction: "http://www.service-now.com/change_task/get", Content-Type: text/xml;charset=UTF-8, Content-Length: 408
DEBUG -- : <?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://www.service-now.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ins0="http://www.service-now.com/change_task"><env:Body><ins0:get><tns:sysId>67d2f77ed9377840c53fc6da9c094635</tns:sysId></ins0:get></env:Body></env:Envelope>
DEBUG -- : HTTPI POST request to xseaddev.service-now.com (net_http)
INFO -- : SOAP response (status 401)
Am i constructing the client incorrectly? I don't see any authentication headers being sent on either the GET or PoST requests.
Do i need to add/remove anything to get this working? Your help would be appreciated.
I imagine you should be able to do the following:
client = Savon.client(endpoint: ENDPOINT, namespace: NAMESPACE, basic_auth: ["user", "password"])
(Or the same in block form).
Check this page under the "Authentication" heading: http://savonrb.com/version2/globals.html
(I am doing the same, but with a WSDL).

Can't get Savon to form the right XML

I've used SOAP before but many, many years ago and try to stay clear if I can help it.
Short story...
Using "Soap Client" OS X app I can get the response I wish.
If I use client.request :foo_web_serivce, :language_count, :body => { :foo_app_id => "...", :session_id => "..." } then I get a Status 200 but my results are -1 as I believe the app_id is not recognised.
If I try to replicate the Soap Client call (<LanguageCount>) rather than Savon's call (<foo_web_service:LanguageCount>) then I get an Status 500.
Please advise and thanks in advance.
Long Story...
Using SOAP Client I can see that the correct request XML is:
User-Agent: Mac OS X; WebServicesCore (357)
Content-Type: text/xml
Host: redacted
Soapaction: http://tempuri.org/redacted/LanguageCount
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<LanguageCount xmlns="http://tempuri.org/">
<fooAppID xsi:type="xsd:string">12345678-1234-1234-1234-123456789123</fooAppID>
<sessionID xsi:type="xsd:string">12345678-1234-1234-1234-123456789123</sessionID>
</LanguageCount>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
However, when I try to do it in the console like so:
ruby-1.8.7-p302 > client = Savon::Client.new do |wsdl, http, wsse|
ruby-1.8.7-p302 > wsdl.document = "http://FooService.cloudapp.net/FooService.svc?wsdl"
ruby-1.8.7-p302 ?> end
=> #<Savon::Client:0x1055e2dc8 #http=#<HTTPI::Request:0x1055e2bc0>, #wsse=#<Savon::WSSE:0x1055e2b98>, #wsdl=#<Savon::WSDL::Document:0x1055e2c10 #request=#<HTTPI::Request:0x1055e2bc0>, #document="http://FooService.cloudapp.net/FooService.svc?wsdl">>
ruby-1.8.7-p302 >
ruby-1.8.7-p302 > client.request :language_count, :body => {:Foo_app_id => "12345678-1234-1234-1234-123456789123", :session_id => "12345678-1234-1234-1234-123456789123"}
Retrieving WSDL from: http://FooService.cloudapp.net/FooService.svc?wsdl
HTTPI executes HTTP GET using the net_http adapter
SOAP request: http://Fooservice.cloudapp.net/FooService.svc
SOAPAction: "LanguageCount", Content-Type: text/xml;charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:wsdl="http://tempuri.org/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><LanguageCount><FooAppId>12345678-1234-1234-1234-123456789123</FooAppId><sessionId>12345678-1234-1234-1234-123456789123</sessionId></LanguageCount></env:Body></env:Envelope>
HTTPI executes HTTP POST using the net_http adapter
SOAP response (status 500):
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><s:Fault><faultcode xmlns:a="http://schemas.microsoft.com/ws/2005/05/addressing/none">a:ActionNotSupported</faultcode><faultstring xml:lang="en-US">The message with Action 'LanguageCount' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).</faultstring></s:Fault></s:Body></s:Envelope>
Savon::SOAP::Fault: (a:ActionNotSupported) The message with Action 'LanguageCount' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
But when I use the namespace of foo_web_service, I get:
ruby-1.8.7-p302 > client = Savon::Client.new do |wsdl, http, wsse| ruby-1.8.7-p302 > wsdl.document = "http://FooService.cloudapp.net/FooService.svc?wsdl" ruby-1.8.7-p302 ?> end =>
#<Savon::Client:0x105882498 #http=#<HTTPI::Request:0x105882358>, #wsse=#<Savon::WSSE:0x105882330>, #wsdl=#<Savon::WSDL::Document:0x105882380 #request=#<HTTPI::Request:0x105882358>, #document="http://FooService.cloudapp.net/FooService.svc?wsdl">> ruby-1.8.7-p302 > ruby-1.8.7-p302 > client.request :Foo_web_service, :language_count, :body => {:Foo_app_id
=> "12345678-1234-1234-1234-123456789123", :session_id => "12345678-1234-1234-1234-123456789123"} Retrieving WSDL from: http://FooService.cloudapp.net/FooService.svc?wsdl HTTPI executes HTTP GET using the net_http adapter SOAP request: http://Fooservice.cloudapp.net/FooService.svc SOAPAction: "http://tempuri.org/FooService/LanguageCount", Content-Type: text/xml;charset=UTF-8 <?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:Foo_web_service="http://tempuri.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><Foo_web_service:LanguageCount><FooAppId>12345678-1234-1234-1234-123456789123</FooAppId><sessionId>12345678-1234-1234-1234-123456789123</sessionId></Foo_web_service:LanguageCount></env:Body></env:Envelope> HTTPI executes HTTP POST using the net_http adapter SOAP response (status 200): <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><LanguageCountResponse xmlns="http://tempuri.org/"><LanguageCountResult>-1</LanguageCountResult></LanguageCountResponse></s:Body></s:Envelope>
=> #<Savon::SOAP::Response:0x105a2cca8 #http=#<HTTPI::Response:0x105a28ce8 #body="<s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\"><s:Body><LanguageCountResponse xmlns=\"http://tempuri.org/\"><LanguageCountResult>-1</LanguageCountResult></LanguageCountResponse></s:Body></s:Envelope>", #raw_body="<s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\"><s:Body><LanguageCountResponse xmlns=\"http://tempuri.org/\"><LanguageCountResult>-1</LanguageCountResult></LanguageCountResponse></s:Body></s:Envelope>", #code=200, #headers={"x-powered-by"=>"ASP.NET", "x-aspnet-version"=>"4.0.30319", "content-type"=>"text/xml; charset=utf-8", "date"=>"Sat, 02 Jul 2011 23:40:56 GMT", "server"=>"Microsoft-IIS/7.0", "content-length"=>"214", "cache-control"=>"private"}>, #soap_fault=Savon::SOAP::Fault, #http_error=Savon::HTTP::Error> ruby-1.8.7-p302 >
Long story short, I had to make 3 changes.
Changed response = client.request :language_count to
response = client.request "LanguageCount"
Added :xmlns => "http://tempuri.org/" to the end of the client.request call
Explicitly called the SOAPaction like: client.http.headers["SOAPAction"] = '"http://tempuri.org/FooService/LanguageCount"'
Hope this helps someone as I've been in SOAP hell for the weekend and hopefully I'll stop someone else being there.

Ruby 'savon_model' gem soap request - initial request is anonymous. Second authenticated request returns successful response but times out

I am just starting out in the ruby on rails world and have managed to get the below model to make a request and return a response. It uses the 'savon_model' gem which has 'savon', 'httpi' and 'httpclient' gems as dependencies.
class Incident
include Savon::Model
client do
http.auth.basic "testuser", ""
http.headers["Accept-Encoding"] = "gzip, deflate"
http.headers["SOAPAction"] = '"RetrieveKeysList"'
end
endpoint "http://localhost:13080/SM/7/ws"
namespace "http://schemas.hp.com/SM/7"
actions "RetrieveIncidentKeysListRequest"
def self.all
response = client.request("RetrieveIncidentKeysListRequest") do
soap.body = {'wsdl:model' =>
{'wsdl:keys' =>"",
'wsdl:instance' =>""}
}
end
h = response.to_hash
ActiveRecord::Base.logger.debug "********value of H is #{h}"
return h[:retrieve_incident_keys_list_response][:keys]
end
end
I have 2 issues:
1) The request makes an anonymous soap request first, fails authentication, then makes a second request, authenticates correctly and returns a response.The response returns within a second or so. Is there something wrong in my model code that is causing the initial anonymous request?
POST /SM/7/ws HTTP/1.1
accept-encoding: gzip, deflate
soapaction: "RetrieveKeysList"
content-type: text/xml;charset=UTF-8
date: Mon, 13 Dec 2010 12:54:11 GMT
content-length: 427
host: localhost:13080
<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://schemas.hp.com/SM/7" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><RetrieveIncidentKeysListRequest><wsdl:model><wsdl:keys></wsdl:keys><wsdl:instance></wsdl:instance></wsdl:model></RetrieveIncidentKeysListRequest></env:Body></env:Envelope>
HTTP/1.1 401
Set-Cookie: JSESSIONID=E7FFF77B44531BE3E28B239F0A900A5A; Path=/SM
WWW-Authenticate: Basic realm="CASM"
Connection: close
Content-Type: text/html;charset=utf-8
Content-Length: 40
Date: Mon, 13 Dec 2010 12:54:11 GMT
POST /SM/7/ws HTTP/1.1
accept-encoding: gzip, deflate
soapaction: "RetrieveKeysList"
content-type: text/xml;charset=UTF-8
cookie: JSESSIONID=E7FFF77B44531BE3E28B239F0A900A5A
authorization: Basic ZmFsY29uOg==
date: Mon, 13 Dec 2010 12:54:12 GMT
content-length: 427
host: localhost:13080
<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://schemas.hp.com/SM/7" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><RetrieveIncidentKeysListRequest><wsdl:model><wsdl:keys></wsdl:keys><wsdl:instance></wsdl:instance></wsdl:model></RetrieveIncidentKeysListRequest></env:Body></env:Envelope>
HTTP/1.1 200
Set-Cookie: JSESSIONID=21EE41B79757FA9C0E31FAB886A2899D; Path=/SM
Keep-Alive: timeout=1200000, max=1000
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/xml;charset=utf-8
Content-Length: 9014
Date: Mon, 13 Dec 2010 12:54:14 GMT
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><RetrieveIncidentKeysListResponse xmlns="http://schemas.hp.com/SM/7" xmlns:cmn="http://schemas.hp.com/SM/7/Common" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" message="Success" query="" returnCode="0" schemaRevisionDate="2010-08-26" schemaRevisionLevel="1" status="SUCCESS" xsi:schemaLocation="http://schemas.hp.com/SM/7 http://localhost:13080/SM/7/ws/Incident.xsd"><keys><IncidentID type="String">IM10001</IncidentID></keys><keys><IncidentID type="String">IM10002</IncidentID></keys><keys><IncidentID type="String">IM10003</IncidentID></keys><keys><IncidentID type="String">IM10004</IncidentID></keys><keys><IncidentID type="String">IM10005</IncidentID></keys><keys><IncidentID type="String">IM10006</IncidentID></keys><keys><IncidentID type="String">IM10007</IncidentID></keys><keys><IncidentID type="String">IM10008</IncidentID></keys><keys><IncidentID type="String">IM10009</IncidentID></keys><keys><IncidentID type="String">IM10010</IncidentID></keys><keys><IncidentID type="String">IM10011</IncidentID></keys><keys><IncidentID type="String">IM10012</IncidentID></keys><keys><IncidentID type="String">IM10014</IncidentID></keys><keys><IncidentID type="String">IM10015</IncidentID></keys><keys><IncidentID type="String">IM10016</IncidentID></keys><keys><IncidentID type="String">IM10017</IncidentID></keys><keys><IncidentID type="String">IM10018</IncidentID></keys><keys><IncidentID type="String">IM10019</IncidentID></keys><keys><IncidentID type="String">IM10020</IncidentID></keys><keys><IncidentID type="String">IM10021</IncidentID></keys><keys><IncidentID type="String">IM10022</IncidentID></keys><keys><IncidentID type="String">IM10023</IncidentID></keys><keys><IncidentID type="String">IM10024</IncidentID></keys><keys><IncidentID type="String">IM10025</IncidentID></keys><keys><IncidentID type="String">IM10026</IncidentID></keys><keys><IncidentID type="String">IM10027</IncidentID></keys><keys><IncidentID type="String">IM10028</IncidentID></keys><keys><IncidentID type="String">IM10029</IncidentID></keys><keys><IncidentID type="String">IM10030</IncidentID></keys><keys><IncidentID type="String">IM10031</IncidentID></keys><keys><IncidentID type="String">IM10032</IncidentID></keys><keys><IncidentID type="String">IM10033</IncidentID></keys><keys><IncidentID type="String">IM10034</IncidentID></keys><keys><IncidentID type="String">IM10035</IncidentID></keys><keys><IncidentID type="String">IM10036</IncidentID></keys><keys><IncidentID type="String">IM10037</IncidentID></keys><keys><IncidentID type="String">IM10038</IncidentID></keys><keys><IncidentID type="String">IM10039</IncidentID></keys><keys><IncidentID type="String">IM10040</IncidentID></keys><keys><IncidentID type="String">IM10041</IncidentID></keys><keys><IncidentID type="String">IM10042</IncidentID></keys><keys><IncidentID type="String">IM10043</IncidentID></keys><keys><IncidentID type="String">IM10044</IncidentID></keys><keys><IncidentID type="String">IM10045</IncidentID></keys><keys><IncidentID type="String">IM10046</IncidentID></keys><keys><IncidentID type="String">IM10047</IncidentID></keys><keys><IncidentID type="String">IM10048</IncidentID></keys><keys><IncidentID type="String">IM10049</IncidentID></keys><keys><IncidentID type="String">IM10050</IncidentID></keys><keys><IncidentID type="String">IM10051</IncidentID></keys><keys><IncidentID type="String">IM10052</IncidentID></keys><keys><IncidentID type="String">IM10053</IncidentID></keys><keys><IncidentID type="String">IM10054</IncidentID></keys><keys><IncidentID type="String">IM10055</IncidentID></keys><keys><IncidentID type="String">IM10057</IncidentID></keys><keys><IncidentID type="String">IM10058</IncidentID></keys><keys><IncidentID type="String">IM10059</IncidentID></keys><keys><IncidentID type="String">IM10060</IncidentID></keys><keys><IncidentID type="String">IM10061</IncidentID></keys><keys><IncidentID type="String">IM10062</IncidentID></keys><keys><IncidentID type="String">IM10063</IncidentID></keys><keys><IncidentID type="String">IM10064</IncidentID></keys><keys><IncidentID type="String">IM10065</IncidentID></keys><keys><IncidentID type="String">IM10066</IncidentID></keys><keys><IncidentID type="String">IM10067</IncidentID></keys><keys><IncidentID type="String">IM10068</IncidentID></keys><keys><IncidentID type="String">IM10069</IncidentID></keys><keys><IncidentID type="String">IM10070</IncidentID></keys><keys><IncidentID type="String">IM10071</IncidentID></keys><keys><IncidentID type="String">IM10072</IncidentID></keys><keys><IncidentID type="String">IM10073</IncidentID></keys><keys><IncidentID type="String">IM10074</IncidentID></keys><keys><IncidentID type="String">IM10075</IncidentID></keys><keys><IncidentID type="String">IM10076</IncidentID></keys><keys><IncidentID type="String">IM10077</IncidentID></keys><keys><IncidentID type="String">IM10078</IncidentID></keys><keys><IncidentID type="String">IM10079</IncidentID></keys><keys><IncidentID type="String">IM10080</IncidentID></keys><keys><IncidentID type="String">IM10081</IncidentID></keys><keys><IncidentID type="String">IM10082</IncidentID></keys><keys><IncidentID type="String">IM10083</IncidentID></keys><keys><IncidentID type="String">IM10084</IncidentID></keys><keys><IncidentID type="String">IM10085</IncidentID></keys><keys><IncidentID type="String">IM10086</IncidentID></keys><keys><IncidentID type="String">IM10087</IncidentID></keys><keys><IncidentID type="String">IM10088</IncidentID></keys><keys><IncidentID type="String">IM10089</IncidentID></keys><keys><IncidentID type="String">IM10090</IncidentID></keys><keys><IncidentID type="String">IM10091</IncidentID></keys><keys><IncidentID type="String">IM10092</IncidentID></keys><keys><IncidentID type="String">IM10093</IncidentID></keys><keys><IncidentID type="String">IM10094</IncidentID></keys><keys><IncidentID type="String">IM10095</IncidentID></keys><keys><IncidentID type="String">IM10096</IncidentID></keys><keys><IncidentID type="String">IM10097</IncidentID></keys><keys><IncidentID type="String">IM10098</IncidentID></keys><keys><IncidentID type="String">IM10099</IncidentID></keys><keys><IncidentID type="String">IM10100</IncidentID></keys><keys><IncidentID type="String">IM10101</IncidentID></keys><keys><IncidentID type="String">IM10102</IncidentID></keys><keys><IncidentID type="String">IM10103</IncidentID></keys><keys><IncidentID type="String">IM10104</IncidentID></keys><keys><IncidentID type="String">IM10105</IncidentID></keys><keys><IncidentID type="String">IM10106</IncidentID></keys><keys><IncidentID type="String">IM10107</IncidentID></keys><keys><IncidentID type="String">IM10108</IncidentID></keys><keys><IncidentID type="String">IM10109</IncidentID></keys><keys><IncidentID type="String">IM10110</IncidentID></keys><keys><IncidentID type="String">IM10111</IncidentID></keys><keys><IncidentID type="String">IM10112</IncidentID></keys><keys><IncidentID type="String">IM10113</IncidentID></keys><keys><IncidentID type="String">IM10114</IncidentID></keys><keys><IncidentID type="String">IM10115</IncidentID></keys><keys><IncidentID type="String">IM10116</IncidentID></keys><keys><IncidentID type="String">IM10117</IncidentID></keys><keys><IncidentID type="String">IM10118</IncidentID></keys><keys><IncidentID type="String">IM10119</IncidentID></keys><keys><IncidentID type="String">IM10120</IncidentID></keys><keys><IncidentID type="String">IM10121</IncidentID></keys><keys><IncidentID type="String">IM10122</IncidentID></keys><keys><IncidentID type="String">IM10123</IncidentID></keys><keys><IncidentID type="String">IM10124</IncidentID></keys><keys><IncidentID type="String">IM10125</IncidentID></keys><keys><IncidentID type="String">IM10126</IncidentID></keys><keys><IncidentID type="String">IM10127</IncidentID></keys><keys><IncidentID type="String">IM10128</IncidentID></keys><keys><IncidentID type="String">IM10129</IncidentID></keys><keys><IncidentID type="String">IM10130</IncidentID></keys><keys><IncidentID type="String">IM10131</IncidentID></keys><keys><IncidentID type="String">IM10132</IncidentID></keys><keys><IncidentID type="String">IM10133</IncidentID></keys><keys><IncidentID type="String">IM10134</IncidentID></keys><keys><IncidentID type="String">IM10135</IncidentID></keys><keys><IncidentID type="String">IM10136</IncidentID></keys><keys><IncidentID type="String">IM10137</IncidentID></keys><keys><IncidentID type="String">IM10138</IncidentID></keys><keys><IncidentID type="String">IM10140</IncidentID></keys><keys><IncidentID type="String">IM10141</IncidentID></keys><keys><IncidentID type="String">IM10142</IncidentID></keys><keys><IncidentID type="String">IM10143</IncidentID></keys><keys><IncidentID type="String">IM10144</IncidentID></keys><keys><IncidentID type="String">IM10145</IncidentID></keys></RetrieveIncidentKeysListResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
2) Even though the request is parsed and response returned as in the above log (which is from request application not rails app), the request times out on the rails side and nothing is written to screen. Below is the development.log entries and last few lines of the stack trace:
development.log
Started GET "/incidents" for 127.0.0.1 at 2010-12-13 12:59:33 +0000
Processing by IncidentsController#index as HTML
Completed in 63517ms
HTTPClient::ReceiveTimeoutError (execution expired):
app/models/incident.rb:15:in `all'
app/controllers/incidents_controller.rb:5:in `index'
Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/actionpack-3.0.0/lib/action_dispatch/middleware/templates/rescues/_trace.erb (1.0ms)
Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/actionpack-3.0.0/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (2.0ms)
Rendered C:/Ruby192/lib/ruby/gems/1.9.1/gems/actionpack-3.0.0/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout
Last few lines of Stack Trace
httpclient (2.1.5.2) lib/httpclient/session.rb:804:in `readpartial'
httpclient (2.1.5.2) lib/httpclient/session.rb:804:in `block in read_body_length'
httpclient (2.1.5.2) lib/httpclient/timeout.rb:128:in `timeout'
httpclient (2.1.5.2) lib/httpclient/session.rb:802:in `read_body_length'
httpclient (2.1.5.2) lib/httpclient/session.rb:591:in `get_body'
httpclient (2.1.5.2) lib/httpclient.rb:958:in `do_get_block'
httpclient (2.1.5.2) lib/httpclient.rb:765:in `block in do_request'
httpclient (2.1.5.2) lib/httpclient.rb:848:in `protect_keep_alive_disconnected'
httpclient (2.1.5.2) lib/httpclient.rb:764:in `do_request'
httpclient (2.1.5.2) lib/httpclient.rb:666:in `request'
httpclient (2.1.5.2) lib/httpclient.rb:596:in `post'
httpi (0.7.2) lib/httpi/adapter/httpclient.rb:34:in `block in post'
httpi (0.7.2) lib/httpi/adapter/httpclient.rb:66:in `do_request'
httpi (0.7.2) lib/httpi/adapter/httpclient.rb:33:in `post'
httpi (0.7.2) lib/httpi.rb:93:in `block in post'
httpi (0.7.2) lib/httpi.rb:147:in `with'
httpi (0.7.2) lib/httpi.rb:91:in `post'
Apologies for the long winded message, any help would be greatly appreciated.
Thanks
Joel

Resources