shindig error: At least 1 ModulePrefs is required - opensocial

I have Shindig 2.0.2 server running. When I'm trying to render the following local gadget spec XML:
<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs title="Calendar">
<Require feature="opensocial-0.7" />
</ModulePrefs>
<Content type="url" href='../../Base/content/calendar/index.html'>
</Content>
</Module>
I get this error:
At least 1 ModulePrefs is required.
Does anyone knows this error?
Also when I run my server localy, there is no problem. The error occurs only when my app and Shindig are deployed on cloud (under https).
Thanks!

The problem was that Shindig got the SAML redirection HTML page so it could not be parsed correctly.

Related

RPC Request for get-schema of bbf(broadband forum) yangs

I am trying below RPC request for module bbf-dot1q-types. but facing error like identifier is not found.
Please help me on this to what is the right RPC request for bbf yangs.
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>bbf-dot1q-types</identifier>
</get-schema>
</rpc>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-info>
<err-element>identifier</err-element>
</error-info>
<error-message>
MINOR: MGMT_CORE #2301: Invalid element value
</error-message>
</rpc-error>
</rpc-reply>
Seems like the Netconf server handling your request does not have the bbf-dot1q-types module loaded. See RFC 6022, 3.1. The <get-schema> Operation:
If the requested schema does not exist, the <error-tag> is 'invalid-value'.
Make sure the Netconf server loads the module.

Wildfly 13.0.0.Final error UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character ä in request-target

We have recently migrated and deployed our application.EAR (API's) packages in wildfly 13.0.0.Final from GlassFish 3 in Linux environment. While testing application api's its not supporting scandic characters and giving below error (Error copied from server.log from wildfly). But the same test request working fine with the application api's deployed in GlassFish server. I tried to study so many blogs related to wildfly but could not get any solutions. Could some one help here please.
I tired below setting changes in standalone.xml file to set the charset to UTF-8, but its not helped.
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" url-charset="UTF-8"/>
<servlet-container name="default" default-encoding="UTF-8">
2018-07-13 17:06:45,189 DEBUG [io.undertow.request.io] (default I/O-4) UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character ä in request-target
at io.undertow.server.protocol.http.HttpRequestParser.handleQueryParameters(HttpRequestParser.java:523)
at io.undertow.server.protocol.http.HttpRequestParser.beginQueryParameters(HttpRequestParser.java:486)
at io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:410)
at io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:147)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:93)
at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:52)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
Below is the request XML which we are sending to application deployed in both Wildfly and GlassFish
<SOAP-ENV:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/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/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<StartHeader SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="0" xmlns="http://www.openuri.org/2002/04/soap/conversation/">
<callbackLocation>http://TESTUI</callbackLocation>
</StartHeader>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ListAttributeValues xmlns="http://www.openuri.org/" xmlns:v001="http://xml.comptel.com/NIMS/address/listAttribteValuesRequest/v002" xmlns:v0011="http://xml.comptel.com/NIMS/address/v002">
<listAttributeValuesRequest xsi:schemaLocation="http://xml.comptel.com/NIMS/address/listAttributeValuesRequest/v002 http://xml.comptel.com/NIMS/address/listAttributeValuesRequest/v002" xmlns="http://xml.comptel.com/NIMS/address/listAttributeValuesRequest/v002" xmlns:spec="http://xml.comptel.com/NIMS/address/v002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spec:searchItemList>
<spec:attribute>
<spec:name>district</spec:name>
<spec:value>Jär</spec:value>
</spec:attribute>
</spec:searchItemList>
<spec:attributeName>district</spec:attributeName>
<spec:maxItems>100</spec:maxItems>
</listAttributeValuesRequest>
</ListAttributeValues>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Finally i managed to fix the problem with help of JBossDevelopers community
I don't think it's the contents of SOAP message that is the problem, but the URI that is used to touch the web service. Problem can be fixed using any of the below option. Option 2 will be recommended for latest wildfly versions where undertow subsystem introduced.
By adding the following Java option to startup script :
-Dorg.wildfly.undertow.ALLOW_UNESCAPED_CHARACTERS_IN_URL=true
or we can set the allow-unescaped-characters-in-url="true" and url-charset="windows-1252" flags in the undertow subsystem in standalone.xml file.
I think these options were added as part of the undertow:6.0 schema as attributes of the https-listener and http-listener elements.
See here:
wildfly/wildfly-undertow_6_0.xsd at master · wildfly/wildfly · GitHub
An example configuration:
wildfly/undertow-6.0.xml at master · wildfly/wildfly · GitHub

CISCO WebDialer API, The AXIS engine could not find a target service to invoke

I'm trying to use Cisco WebDialer API but have a few issues with it:
When I try to send the following SOAP request
<?xml version="1.0" encoding="utf-8" ?>
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:WD70">
<soapenv:Header/>
<soapenv:Body>
<urn:makeCallSoap soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<in0 xsi:type="urn:Credential">
<userID xsi:type="xsd:string">user******</userID>
<password xsi:type="xsd:string">pass*****</password>
</in0>
<in1 xsi:type="soapenc:string" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">1234</in1>
<in2 xsi:type="urn:UserProfile">
<user xsi:type="xsd:string">wd</user>
<deviceName xsi:type="xsd:string">SEP001558C8970F</deviceName>
<lineNumber xsi:type="xsd:string">901234565</lineNumber>
<supportEM xsi:type="xsd:boolean">false</supportEM>
<locale xsi:type="xsd:string">English</locale>
<dontAutoClose xsi:type="xsd:boolean">false</dontAutoClose>
<dontShowCallConf xsi:type="xsd:boolean">true</dontShowCallConf>
</in2>
</urn:makeCallSoap>
</soapenv:Body>
</soapenv:Envelope>
to https://SERVER:PORT/webdialer/services/WebdialerSoapService70 I got the following error:
The AXIS engine could not find a target service to invoke! targetService is WebdialerSoapService70
When I try to access directly https:///webdialer/services/WebdialerSoapService70 via browser I get the following message:
AXIS error
No service is available at this URL
My question is what is wrong? Do I miss something in my request or required service isn't running?
Thank you.
Ok, thanks to my colleague I've got the answer. You need to go to the following link:
https://SERVER:PORT/webdialer/services
And you'll see list of all working services and links to them. In my case right link was:
https://SERVER:PORT/webdialer/services/WebdialerSoapService
After I've changed it everything begin to work. And yes, when you open right link in browser you have to get the following message:
WebdialerSoapService
Hi there, this is an AXIS service!
Perhaps there will be a form for invoking the service here...

Hand-crafted WSDL from XSD fails in CXF: the namespace on the "QueryResponse" element, is not a valid SOAP version

I have a web service that follows some of the semantics of a SOAP service, but they don't provide a WSDL for said service. Instead, they provide an XSD, by which I'm reverse-engineering a WSDL out of. Things seemed to be going well, even so far as to be able to
create a WSDL
Import the XSD as part of the WSDL using the xsd:import tag
Create Java wrappers with CXF
Call the service.
Now, what I get when I call the service is an exception:
INFO: Creating Service {http://service.something.net/xml}QueryService from WSDL: file:/C:/mydocs/Work/project/my-service.wsdl
Aug 09, 2011 1:22:34 PM org.apache.cxf.phase.PhaseInterceptorChain doDefaultLogging
WARNING: Interceptor for {http://service.something.net/xml}QueryService#{http://servicesomething..../xml}QueryRequest has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: "http://service.something.net/xml", the namespace on the "QueryResponse" element, is not a valid SOAP version.
The WSDL can be found in this gist, and the XSD is something I got from the vendor.
What does the error mean? What might I have done wrong in my .wsdl file generation?
Edit 1
I have manually tested the service from the vendor service, and the response seems okay to me:
<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<QueryResponse xmlns="http://service.something.net/xml">
....
</QueryResponse>
</Body>
</Envelope>
Unless I'm missing something, there should not be any reason why CXF even wants the QueryResponse to be a SOAP element, since it's namespace isn't SOAP but http://service.something.net/xml.
Where you are importing your XSD:
<wsdl:types>
<xsd:schema targetNamespace="http://service.something.net/xml">
<xsd:include schemaLocation="My-XSD.xsd" />
</xsd:schema>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://service.something.net/xml"
schemaLocation="My-XSD.xsd">
</xsd:import>
</xsd:schema>
</wsdl:types>
try this instead:
<wsdl:types>
<xs:schema targetNamespace="http://service.something.net/xml"
elementFormDefault="qualified">
<xs:import schemaLocation="My-XSD.xsd"/>
</xs:schema>
</wsdl:types>
Basically you shouldn't need the include, just the import. Also you want to specify fully qualified element form.
Hope this works.

Why are my entities disapearing after deploy?

I created an OData service for a couple of our entities, and on my developer machine (WinXP), everything works like it should, this is what I get when accessing the service:
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<service xml:base="http://localhost:2332/ContactOData.svc/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app" xmlns="http://www.w3.org/2007/app">
<workspace>
<atom:title>Default</atom:title>
<collection href="Client">
<atom:title>Client</atom:title>
</collection>
<collection href="Vehicle">
<atom:title>Vehicle</atom:title>
</collection>
<collection href="Contact">
<atom:title>Contact</atom:title>
</collection>
</workspace>
</service>
Now after I deployed that service to a testserver (Win2K3), all my entities are gone:
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<service xml:base="http://dev-cont2011b/ContactOData/ContactOData.svc/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app" xmlns="http://www.w3.org/2007/app">
<workspace>
<atom:title>Default</atom:title>
</workspace>
</service>
There are no error messages, nothing in the event log. My connections string is ok (I tested this with a simple test.aspx page which fetches something out of the database and shows it on the page ==> this works).
When I manually enter the url for one of the entities (Client), this is what I get:
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<code></code>
<message xml:lang="nl-BE">Resource not found for the segment 'Client'.</message>
</error>
The .NET Framework 3.5 is installed on that server. I ran all the updates.
I've been banging my head on this one for the last couple of hours. I don't know what else I can do or test.
Any suggestions?
The solution was to install this update:
ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows Server 2003, Windows XP, Windows Vista and Windows Server 2008
Apparently, this one isn't included into windows update by default. You have to run it manually.
This was needed because I changed the default InitializeService method so it takes a DataServiceConfiguration in stead of an IDataServiceConfiguration:
public static void InitializeService(DataServiceConfiguration config)
{
config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
config.DataServiceBehavior.MaxProtocolVersion = System.Data.Services.Common.DataServiceProtocolVersion.V2;
config.SetEntitySetPageSize("*", 20);
}
This is needed if you want to enable server side paging (SetEntitySetPageSize) (amongst others).
New try:
It is a RESX problem
<message xml:lang="nl-BE">Resource not found for the segment 'Client'.</message>
It is trying to lookup the nl-BE translation for the name Client.