Does it work out to have a RESTful webservice using document style SOAP as messaging format ?
I found a passage in the book SOA Expertenwissen (page 403):
"Es ist durchaus möglich, wenn auch unüblich, auch in einer REST-konformen Anwendung SOAP einzusetzen, um Nachrichten mit Header-Elementen für die Abbildung nichtfunktionaler Charakteristika anzureichern."
In English:
It is possible but unusual to use SOAP in a REST compliant application. It is useful to include SOAP headers for providing non-functional information.
Related
I am trying to get "mutual friends" and "mutual likes" between session-user(i.e. me) and request-user(i.e. some friend of friend) using Graph Api Explorer, but i am receiving an empty list.
The urls I am hitting :
for mutual friends :
http://graph.facebook.com/[request-user-id]?fields=context.fields(mutual_friends)&access_token=[my-access-token]
for mutual likes :
http://graph.facebook.com/[request-user-id]?
fields=context.fields(mutual_likes)&access_token=[my-access-token]
Thanks in advance!!
I am New to BlackBerry development. I am using Momentics for Blackberry development. Now I want to pass an object to my Login webservice. Here is my webservice.
<Login xmlns="http://shidhints.com/">
<MyLoginCredentials>
<Email>string</Email>
<Password>string</Password>
</MyLoginCredentials>
</Login>
How I can create an object of MyLoginCredentials in C++, Please Help me.
I have Resolved it Using the code,
QtSoapStruct *myStruct=new QtSoapStruct(QtSoapQName("MyLoginCredentials"));
myStruct->insert( new QtSoapSimpleType(QtSoapQName("Email"), email));
myStruct->insert( new QtSoapSimpleType(QtSoapQName("Password"),password));
request.addMethodArgument(myStruct);
I am using CXF JAXWS Client for retrieving some information from an external web services. So, basically, we have .xsd and .wsdl files from the external and try to implement our ws consumer by generating the client stubs using cxf-codegen-plugin. We cannot change the .xsd and .wsdl files. Everything works fine, we are able to send and retrieve soap messges from the external services.
However, when I look into the soap request message from the log, I find a lot of unused namespaces in the soap (body) message sent from our ws client.
Below is an example
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:aheaderns="http://xxx.xxx.xxx.xxx/header.xsd">
<soap:Header>
...
</soap:Header>
<soap:Body>
<ns7:requestQuery xmlns:ns15="http://xxx.xxx.xxx.xxx/AAA" xmlns:ns14="http://xxx.xxx.xxx.xxx/BBB" xmlns:ns13="http://xxx.xxx.xxx.xxx/DDD" xmlns:ns12="http://xxx.xxx.xxx.xxx/CCC" xmlns:ns11="http://xxx.xxx.xxx.xxx/EEE" xmlns:ns10="http://xxx.xxx.xxx.xxx/FFF" xmlns:ns9="http://xxx.xxx.xxx.xxx/GGG" xmlns:ns8="http://xxx.xxx.xxx.xxx/HHH" xmlns:ns7="http://xxx.xxx.xxx.xxx/III" xmlns:ns6="http://xxx.xxx.xxx.xxx/JJJ" xmlns:ns5="http://xxx.xxx.xxx.xxx/KKK">
<ns7:sample>
<ns7:type>A</ns7:type>
<ns7:ref>1</ns7:ref>
</ns7:sample>
</ns7:requestQuery>
</soap:Body>
Is there any way to remove the unused namespaces from the outbound soap message sending from the client?
You could move your client proxy classes to the same package and map it to the proposed namespace specified in the wsdl.
Put this code into the package-info.java class:
#XmlSchema(xmlns = { #XmlNs(prefix = "ns1", namespaceURI = "http://xxx.xxx.xxx") },
namespace = "http://xxx.xxx.xxx")
package clinet.sample.proxy;
import javax.xml.bind.annotation.XmlNs;
Hope this helps.
After digging into this problem for quite sometime, I found the solution. However, I think my solution is not to solve the problem at the root cause but it works for now.
Basically, I use XSLTOutInterceptor from CXF to apply the XSL to the out message. However, the default PRE_STEAM phase is not working for me. Then, I decide to extend the XSLTOutInterceptor so as to change its PHASE to WRITE. So that, the unused namespaces will be removed during the writing of the protocol message before sending it out.
The XSL I use is from how to remove unused namespaces from source xml
By the way, I still have no idea why those unused namespaces have been generated. If anyone could give me a suggestion, I would appreciate it.
Thanks :)
Recently I migrated my application from jboss5.1 to Glassfish 3.1.2. Despite other problems I`ve found, now I cannot pass a null parameter to my web method anymore. And it was not a problem in Jboss. What should I do? Is there a flag to allow null parameter through my web melhod.
(My application uses icefaces3.0.1 and JSF 2.0; the WS is a EJB project, also in the same server for now) tks
error:
javax.xml.ws.WebServiceException: Method Parameter: toDate cannot be null. This is BP 1.1 R2211 violation.
The whole thing did get discussed here: https://java.net/jira/browse/JAX_WS-128
JAX-WS 2.0 enforces strict Basic Profile 1.1 compliance. The following
are known cases where .NET framework does not enforce strict BP 1.1
semantics and their usage can lead to interoperability problems.
Also at Oracle: http://docs.oracle.com/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/DataBinding7.html
Not quite sure when but I think I had the same problem when migration from Tomcat 5 to 6
I'm using glassfish 2.1.1. I've watched a mysterious http/webservice-call handling. It seams an http request is handled by two different threads.
After http basic authentication the first thread is faster. Persisting some data end, but writing response fails in glassfish internal.
The second thread fails, because it tries to persist identical data and there are (unique) constrain failures. The response (the failure) of second thread was delivered to client.
I don't won't discuss the behavior with the unique constrain failure. I've improve the webservice, so it can handle this better, because it could be happen anytime, that the client send the ws call a second time.
But I think, glassfish 2.1.1 has an bug handling http request. Is there any known issue? Have I done an mistake?
[#|2010-03-22T10:40:54.150+0000|INFO|sun-appserver2.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting Sun GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12)) (build b31g-fcs) ...|#]
...
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.realm.YaJdbcRealm|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.realm.YaJdbcRealm;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC authenticate successful for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.module.security.auth.login.YaJdbcLoginModule|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.module.security.auth.login.YaJdbcLoginModule;MethodName=authenticate;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|JDBC login succeeded for: 8002 groups:[roleUser]|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Received WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.220+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|Received WebService call to enqueue() from client 59|#]
...
[#|2010-03-22T11:18:44.267+0000|FINE|sun-appserver2.1|mypackage.MyWebService|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;ClassName=mypackage.MyWebService;MethodName=enqueue;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|Successfully finished WebService call to enqueue() from client 59|#]
[#|2010-03-22T11:18:44.329+0000|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=26;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=4d8f23e9-5106-4d64-b865-1638d7075bde;|invocation error on ejb endpoint MyWebService at /MyWebserviceService/MyWebservice : com.sun.xml.stream.XMLStreamException2
javax.xml.ws.WebServiceException: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:111)
at com.sun.xml.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:281)
at com.sun.xml.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:320)
at com.sun.xml.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:93)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:454)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:231)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:157)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.executeServlet(CometEngine.java:616)
at com.sun.enterprise.web.connector.grizzly.comet.CometEngine.handle(CometEngine.java:362)
at com.sun.enterprise.web.connector.grizzly.comet.CometAsyncFilter.doFilter(CometAsyncFilter.java:84)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:189)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:164)
at com.sun.enterprise.web.connector.grizzly.async.AsyncProcessorTask.doTask(AsyncProcessorTask.java:92)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:264)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: com.sun.xml.stream.XMLStreamException2
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:416)
at com.sun.xml.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:109)
... 36 more
Caused by: ClientAbortException: java.nio.channels.ClosedChannelException
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:385)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:351)
at org.apache.coyote.tomcat5.CoyoteOutputStream.flush(CoyoteOutputStream.java:176)
at com.sun.xml.stream.writers.UTF8OutputStreamWriter.flush(UTF8OutputStreamWriter.java:153)
at com.sun.xml.stream.writers.XMLStreamWriterImpl.flush(XMLStreamWriterImpl.java:414)
... 37 more
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:126)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:91)
at com.sun.enterprise.web.connector.grizzly.OutputWriter.flushChannel(OutputWriter.java:66)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:172)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushChannel(AsynchronousOutputBuffer.java:81)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:205)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flushBuffer(AsynchronousOutputBuffer.java:114)
at com.sun.enterprise.web.connector.grizzly.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:183)
at com.sun.enterprise.web.connector.grizzly.async.AsynchronousOutputBuffer.flush(AsynchronousOutputBuffer.java:104)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.action(DefaultProcessorTask.java:1100)
at org.apache.coyote.Response.action(Response.java:237)
at org.apache.coyote.tomcat5.OutputBuffer.doFlush(OutputBuffer.java:381)
... 41 more
|#]
[#|2010-03-22T11:18:44.376+0000|WARNING|sun-appserver2.1|oracle.toplink.essentials.session.file:/mygf-211/domains/mydomain/applications/j2ee-apps/myear/myjar-myPu|_ThreadID=39;_ThreadName=httpSSLWorkerThread-8080-2;_RequestID=4ca7e3e5-5ab7-41ec-b3c9-d9260b1164c9;|
Local Exception Stack:
Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.1 (Build b31g-fcs (10/19/2009))): oracle.toplink.essentials.exceptions.DatabaseException
Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Eine Zeile mit doppeltem Schlüssel kann in das 'dbo.MY_TABLE'-Objekt mit dem eindeutigen 'MY_INDEX'-Index nicht eingefügt werden.
I did a quick search at https://glassfish.dev.java.net/issues/query.cgi and did not see a report that looked like a duplicate of the situation that you are encountering here... though I may have missed it.
You should probably report this issue to the GlassFish developers, via their issue tracker: https://glassfish.dev.java.net/servlets/ProjectIssues.
You may have misread the log or done something wrong in your code, but this is really hard to tell given the limited amount of info that you have given in this question... But, SO doesn't really work as an issue analysis/resolution system. The GF issue tracker is a better choice for that.