RESTful versus Servlet
Hi REST style architecture, being based on HTTP specification, has common conventions like GET, POST typically also used by Servlets. Any idea why one would prefer RESTful Web service and not plain Servlet based framework. Its Web and HTTP in the end. I know this question may not be directly related to CXF but really need to understand the clear semantics between RESTful and Servlet based frameworks. Will appreciate if you could guide me to a post or white paper which has this discussion. Thanks. Raj
Re: Schema validation is not validating elements from SoapHeader
Hi, I think I had the same question some days ago. Check this: http://cxf.547215.n5.nabble.com/Problem-with-validation-of-SOAP-headers-td4686434.html Cheers Andi -- View this message in context: http://cxf.547215.n5.nabble.com/Schema-validation-is-not-validating-elements-from-SoapHeader-tp4705565p4711045.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Returning classes with lists
I would annotate the getColumnNames() and getResultSet() with
@XmlElementWrapper and annotate the QueryResultSet class with
@XmlRootElement
Rob
On Thu, Aug 18, 2011 at 1:22 AM, Barry Hathaway wrote:
> I have a method that returns a class containing a couple of lists; however,
> when it executes I get:
>
> javax.xml.bind.JAXBException: class java.util.ArrayList nor any of its
> super class is known to this context.
>
> The method is:
>
>@WebMethod(operationName="**query", action="urn:query")
>public QueryResultSet query(@WebParam(name="sparcql"**)String sparcql)
>
> where QueryResultSet is:
>
>public class QueryResultSet {
>private List columnNames;
>private List resultSet; <- Object will actually be a
> List
>... getters and setters
>}
>
> How do you go about annotating the classes so the it gets marshalled
> correctly?
> Thanks.
>
> Barry Hathaway
>
>
Re: java.lang.NoClassDefFoundError: org/bouncycastle/asn1/pkcs/PrivateKeyInfo
This got even more weird. My service war includes bcprov-jdk16-1.43.jar which has this class. -- View this message in context: http://cxf.547215.n5.nabble.com/java-lang-NoClassDefFoundError-org-bouncycastle-asn1-pkcs-PrivateKeyInfo-tp4710843p4710930.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: A question about CXF Client Transports
Thank you for your reply! I draw a Sequence Diagram to explain my demand. http://cxf.547215.n5.nabble.com/file/n4710872/Pic.jpg 1.You can see the Part 1 in the Picture. I understand the CPE is Client A and the ACS is Server. As you see the Client A communicate with Server by Inform SOAP message in the Part 1 2.When the CPE send HTTP NO CONTENT message to ACS , the Part 1 is over. But the connection is not close . The Http connect is keep-alive. So In the part2 I understand the CPE act like a Server, the ACS act like a Client. Therefore I want to insert a Client B to ACS. The Client B that is responsible for communicate with the CPE. When ACS send HTTP NO CONTENT message to CPE , the Part 2 is over. The interaction is end. > Well, if it's a different protocol, would it make sense to just develop a > completely new transport conduit and register that with a different uri > scheme? Leave the existing HTTP stuff as is, but create a new transport > for > this. I think your advice is good. But I think My present's ability is limited. Do you have some sample for replacing HTTPConduit ? Can you give me some advice from the Sequence Diagram? -- View this message in context: http://cxf.547215.n5.nabble.com/A-question-about-CXF-Client-Transports-tp4707468p4710872.html Sent from the cxf-user mailing list archive at Nabble.com.
java.lang.NoClassDefFoundError: org/bouncycastle/asn1/pkcs/PrivateKeyInfo
Does CXF 2.4.1 have a dependency on a bouncycastle library? The reason I ask is that we are running CXF 2.4.1 web services on a WLS 11 RHEL 5.5 machine with JDK 1.6.24 and in one environment my web services with digital signatures (via WSS4J) they work and then in my other environment it throws the following exception: org.apache.cxf.interceptor.Fault: org/bouncycastle/asn1/pkcs/PrivateKeyInfo at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:155) ~[cxf-rt-core-2.2.12.jar:2.2.12] at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:86) ~[cxf-rt-frontend-jaxws-2.2.12.jar:2.2.12] at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:121) ~[cxf-rt-core-2.2.12.jar:2.2.12] at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:60) ~[cxf-rt-frontend-jaxws-2.2.12.jar:2.2.12] at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75) ~[cxf-rt-core-2.2.12.jar:2.2.12] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) ~[cxf-rt-core-2.2.12.jar:2.2.12] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) ~[na:1.6.0_24] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[na:1.6.0_24] at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[na:1.6.0_24] at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) ~[cxf-rt-core-2.2.12.jar:2.2.12] at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) ~[cxf-rt-core-2.2.12.jar:2.2.12] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) ~[cxf-api-2.2.12.jar:2.2.12] at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111) [cxf-rt-core-2.2.12.jar:2.2.12] at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:431) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:186) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) [javax.servlet_1.0.0.0_2-5.jar:2.5] at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) [cxf-rt-transports-http-2.2.12.jar:2.2.12] at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681) [weblogic.jar:10.3.4.0] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) [com.bea.core.weblogic.security.identity_1.1.2.1.jar:1.1.2.1] at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) [com.bea.core.weblogic.security.wls_1.0.0.0_6-1-0-0.jar:6.1.0.0] at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183) [weblogic.jar:10.3.4.0] at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454) [weblogic.jar:10.3.4.0] at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207) [com.bea.core.weblogic.workmanager_1.9.0.0.jar:1.9.0.0] at weblogic.work.ExecuteThread.run(ExecuteThread.java:176) [com.bea.core.weblogic.workmanager_1.9.0.0.jar:1.9.0.0] Caused by: java.lang.NoClassDefFoundError: org/bouncycastle/asn1/pkcs/PrivateKeyInfo at org.bouncycastle.jce.provider.JDKKeyFactory.createPrivateKeyFromDERStream(Unknown Sou
RE: dispatch api with ws-addressing
Bugs are submitted. Patches are created, tested, and license granted on:
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/DispatchImpl.java
(revision 1158970)
I checked out the 2.4.1 tag from SVN and patched on that since I am testing on
2.4.1. I tested by running "mvn -Pfastinstall install" in the
rt/frontend/jaxws directory. For some reason, I cannot compile the whole CXF,
so I just stitched the class files created in jaxws back into the cxf-2.4.1.jar
and tested that way. I always get the following build error in the top level
directory if I run that mvn command:
[INFO] Registering compile source root
/home/jpangburn/open_source/apache-cxf-2.4.1/cxfsvn/testutils/target/generated/src/main/java
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO] [cxf-codegen:wsdl2java {execution: generate-sources}]
[INFO] Running wsdl2java in fork mode...
[INFO] Building jar: /tmp/cxf-tmp-855110/cxf-codegen4741067092732935059.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO]
Exit code: 1 - Exception in thread "main"
org.apache.cxf.tools.common.ToolException: Thrown by JAXB:
cvc-complex-type.3.2.2: Attribute 'xjc:recursive' is not allowed to appear in
element 'class'. at line 44 column 28 of schema
jar:file:/home/jpangburn/open_source/apache-cxf-2.4.1/cxfsvn/tools/wsdlto/databinding/jaxb/target/cxf-tools-wsdlto-databinding-jaxb-2.4.1.jar!/org/apache/cxf/tools/wsdlto/databinding/jaxb/W3CEPRJaxbBinding_jaxb22.xml
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:35)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:286)
at
com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.java:77)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:417)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3181)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2658)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2065)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:549)
at
com.sun.tools.xjc.util.ForkContentHandler.startElement(ForkContentHandler.java:110)
at
org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at
com.sun.tools.xjc.reader.internalizer.DOMForestScanner$LocationResolver.startElement(DOMForestScanner.java:141)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:239)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:122)
at
com.sun.tools.xjc.reader.internalizer.DOMForestScanner.scan(DOMForestScanner.java:89)
at
com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.apply(SCDBasedBindingSet.java:180)
at
com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.applyAll(SCDBasedBindingSet.java:138)
at
com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.apply(SCDBasedBindingSet.java:159)
at
com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.applyAll(SCDBasedBindingSet.java:138)
at
com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet$Target.access$700(SCDBasedBindingSet.java:82)
at
com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:237)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:522)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:236)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:85)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:393)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:588)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:240)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:283)
at
org.a
Re: A question about CXF Client Transports
Thank you for your reply! I draw a Sequence Diagram to explain my demand. http://cxf.547215.n5.nabble.com/file/n4710824/Pic.jpg 1.You can see the Part 1 in the Picture. I understand the CPE is Client A and the ACS is Server. As you see the Client A communicate with Server by Inform SOAP message in the Part 1 2.When the CPE send HTTP NO CONTENT message to ACS , the Part 1 is over. But the connection is not close . The Http connect is keep-alive. So In the part2 I understand the CPE act like a Server, the ACS act like a Client. Therefore I want to insert a Client B to ACS. The Client B that is responsible for communicate with the CPE. When ACS send HTTP NO CONTENT message to CPE , the Part 2 is over. The interaction is end. > Well, if it's a different protocol, would it make sense to just develop a > completely new transport conduit and register that with a different uri > scheme? Leave the existing HTTP stuff as is, but create a new transport > for > this. I think your advice is good. But I think My present's ability is limited. Do you have some sample for replacing HTTPConduit ? Can you give me some advice from the Sequence Diagram? -- View this message in context: http://cxf.547215.n5.nabble.com/A-question-about-CXF-Client-Transports-tp4707468p4710824.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: A question about CXF Client Transports
Hi UlhasBhole! Thank you for your reply. I think I want to explain my mean with a Sequence Diagram. http://cxf.547215.n5.nabble.com/file/n4710796/Pic.jpg 1.You can see the Part 1 in the Picture. I understand the CPE is Client A and the ACS is Server. As you see the Client A communicate with Server by Inform SOAP message in the Part 1 2.When the CPE send HTTP NO CONTENT message to ACS , the Part 1 is over. But the connection is not close . The Http connect is keep-alive. So In the part2 I understand the CPE act like a Server, the ACS act like a Client. Therefore I want to insert a Client B to ACS. The Client B that is responsible for communicate with the CPE. When ACS send HTTP NO CONTENT message to CPE , the Part 2 is over. The interaction is end. As you see , My initial idea is to insert Client B to ACS for achieving the above requirements. I don't find some examples of similar requestion. So do you give me some advice? Thanks! -- View this message in context: http://cxf.547215.n5.nabble.com/A-question-about-CXF-Client-Transports-tp4707468p4710796.html Sent from the cxf-user mailing list archive at Nabble.com.
Returning classes with lists
I have a method that returns a class containing a couple of lists;
however, when it executes I get:
javax.xml.bind.JAXBException: class java.util.ArrayList nor any of its
super class is known to this context.
The method is:
@WebMethod(operationName="query", action="urn:query")
public QueryResultSet query(@WebParam(name="sparcql")String sparcql)
where QueryResultSet is:
public class QueryResultSet {
private List columnNames;
private List resultSet; <- Object will actually be a
List
... getters and setters
}
How do you go about annotating the classes so the it gets marshalled
correctly?
Thanks.
Barry Hathaway
Re: Making async interfaces manually with annotations etc?
On 17 August 2011 23:21, Kent Närling wrote:
>
> On 17 August 2011 18:08, Daniel Kulp wrote:
>
>> On Wednesday, August 17, 2011 4:17:58 PM Kent Närling wrote:
>> > I tried ad-hoc and just wrote the interface myself as:
>> >
>> > @WebService
>> >
>> > public interface MyService
>> >
>> > {
>> >
>> > @WebMethod(operationName = "doSomething")
>> >
>> > Future doSomething(
>> >
>> > @WebParam(name = "someParam") String someParam,
>> > AsyncHandler asyncHandler);
>> >
>> > }
>> > But with this I just god the error : "Could not find wsdl:binding
>> operation
>> > info for web method doSomething"
>> >
>> > So I guess this means I would have to annotate some binding information?
>> or
>> > is this impossible to do with annotations?
>>
>> You ALWAYS have to have the non-async versions there. Thus, put your
>> original method signature in there. You can then optionally add the
>> async
>> versions as needed and only for the methods you need.
>>
>> Dan
>>
>>
>>
>> Does this mean that the server side will have to implement the async
> version as well?
> (would be a bit odd if the server has to implement the same method twice?
>
> Since it has to implement the same interface then it has to implement the
> async version...
>
> Also, can the method name & SOAP operation name be the same? or should the
> methods have different names?
>
>
> ie in the above you are saying that I should declare an interface as:
>
> @WebService
>
> public interface MyService
>
> {
>
> @WebMethod(operationName = "doSomething")
>
> DoSomethingResult doSomething(
>
> @WebParam(name = "someParam") String someParam);
>
> @WebMethod(operationName = "doSomething")
>
> Future doSomething(
>
> @WebParam(name = "someParam") String someParam,
>
> AsyncHandler handler);
>
> }
>
>
> Or?
>
I tried to declare it as above, still get the same error as before:
"Could not find wsdl:binding operation info for web method doSomething"
Do I have to
InitiatorSignatureToken
Hi, I'm unable to define the correct policy for SAML_TOKEN_SIGNED. The following gets the STS token and includes it in the request, but now I need sign the message. http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0 http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey I think I've to use InitiatorSignatureToken, but not sure how. Thanks, Vinay
Re: dispatch api with ws-addressing
They both look like bugs to me. Log some issues and patches are ALWAYS
welcome. :-)
Dan
On Wednesday, August 17, 2011 4:19:13 PM Jesse Pangburn wrote:
> Hi,
> I found the cause of the problem to be a bug in this method in CXF (I have
> version 2.4.1): private Map
> createPayloadEleOpNameMap(BindingInfo bindingInfo) { Map
> payloadElementMap = new java.util.HashMap(); for
> (BindingOperationInfo bop : bindingInfo.getOperations()) {
> SoapOperationInfo soi =
> (SoapOperationInfo)bop.getExtensor(SoapOperationInfo.class); if (soi !=
> null) {
> if ("document".equals(soi.getStyle())) {
> // if doc
> if (bop.getOperationInfo().getInput() != null
> &&
> !bop.getOperationInfo().getInput().getMessageParts().isEmpty()) { QName qn
> = bop.getOperationInfo().getInput().getMessagePartByIndex(0)
> .getElementQName();
> payloadElementMap.put(qn.toString(),
> bop.getOperationInfo().getName()); }
> } else if ("rpc".equals(soi.getStyle())) {
> // if rpc
>
> payloadElementMap.put(bop.getOperationInfo().getName().toString(),
> bop.getOperationInfo() .getName());
> }
> }
> }
> return payloadElementMap;
> }
>
> The problem is that it requires the SoapOperationInfo to have a style
> attribute, but in the W3C spec for WSDL it says the style attribute on the
> soap operation is optional, specifically ' If the attribute is not
> specified, it defaults to the value specified in the soap:binding element.
> If the soap:binding element does not specify a style, it is assumed to be
> "document".' So the code needs to check if the soi has a style and if not
> read it from the binding and if not then set it as "document". This is not
> a problem in the WSDLs generated by CXF (as I found out with a HelloWorld
> test) because it creates these optional style attributes, but since W3C
> says people can generate WSDLs without these (and I ran into one) I think
> it's worth fixing.
>
> Unless someone disagrees, I'll create a defect for this and contribute a
> patch.
>
> While reading code and stepping through the debugger to find out where this
> was going wrong, I also found that if you use a SOAPMessage instead of a
> Source then the following function fails (ignoring the exception) and your
> ws-addressing action doesn't get set either- if you have any whitespace
> after the soap:body element before your first payload element: private
> String getPayloadElementName(SOAPMessage soapMessage) { try {
> SOAPElement element =
> (SOAPElement)soapMessage.getSOAPBody().getChildElements().next(); return
> new QName(element.getNamespaceURI(), element.getLocalName()).toString(); }
> catch (Exception e) {
> //ignore
> }
> return null;
>
> }
>
> This fails because the .next() call at the end gets a text node instead of
> an element object so the cast fails. So inexplicably your ws-addressing
> action header doesn't get set in this case either. Unless someone
> disagrees, I'll create a defect for this as well and contribute a patch.
>
> Thanks so much for your help! I wouldn't have gone looking and found this
> out without knowing it *should* work.
>
> Jesse
>
> -Original Message-
> From: Jesse Pangburn
> Sent: Wednesday, August 17, 2011 11:17 AM
> To: 'Daniel Kulp'; users@cxf.apache.org
> Subject: RE: dispatch api with ws-addressing
>
> Hi Dan,
> Thanks for the suggestion, I'm trying to figure out one of those cases. I
> changed the code to this to try a DOMSource instead: Dispatch disp
> = service.createDispatch(new QName("urn:ihe:iti:xds-b:2007",
> "DocumentRegistry_Port_Soap12"), Source.class, Service.Mode.PAYLOAD, new
> AddressingFeature()); InputStream is =
> IBServer.class.getResourceAsStream("RegistryQuery.xml"); Document doc =
> XMLUtils.parse(is);
> DOMSource reqMsg = new DOMSource(doc);
> Source response = disp.invoke(reqMsg);
>
> DOMSource also sent the same wrong action header. I see that I get back a
> StaxSource (CXF StaxSource, not javax StAXSource) in this case so I tried
> using that as the input next: Dispatch disp =
> service.createDispatch(new QName("urn:ihe:iti:xds-b:2007",
> "DocumentRegistry_Port_Soap12"), Source.class, Service.Mode.PAYLOAD, new
> AddressingFeature()); InputStream is =
> IBServer.class.getResourceAsStream("RegistryQuery.xml"); XMLInputFactory
> xmlInputFactory = XMLInputFactory.newFactory();
> XMLStreamReader xmlStreamReader =
xmlInputFactory.createXMLStreamReader(is,
> "UTF-8"); StaxSource staxSource = new StaxSource(xmlStreamReader);
> Source response = disp.invoke(staxSource);
>
> StaxSource also sent the same wrong action header. I also tried SAXSource:
> InputSource inputSource = new InputSource(is);
> SAXSource saxSource = new SAXSource(inputSource);
> Source response = disp.invoke(sax
RE: dispatch api with ws-addressing
Hi,
I found the cause of the problem to be a bug in this method in CXF (I have
version 2.4.1):
private Map createPayloadEleOpNameMap(BindingInfo
bindingInfo) {
Map payloadElementMap = new java.util.HashMap();
for (BindingOperationInfo bop : bindingInfo.getOperations()) {
SoapOperationInfo soi =
(SoapOperationInfo)bop.getExtensor(SoapOperationInfo.class);
if (soi != null) {
if ("document".equals(soi.getStyle())) {
// if doc
if (bop.getOperationInfo().getInput() != null
&&
!bop.getOperationInfo().getInput().getMessageParts().isEmpty()) {
QName qn =
bop.getOperationInfo().getInput().getMessagePartByIndex(0)
.getElementQName();
payloadElementMap.put(qn.toString(),
bop.getOperationInfo().getName());
}
} else if ("rpc".equals(soi.getStyle())) {
// if rpc
payloadElementMap.put(bop.getOperationInfo().getName().toString(),
bop.getOperationInfo()
.getName());
}
}
}
return payloadElementMap;
}
The problem is that it requires the SoapOperationInfo to have a style
attribute, but in the W3C spec for WSDL it says the style attribute on the soap
operation is optional, specifically ' If the attribute is not specified, it
defaults to the value specified in the soap:binding element. If the
soap:binding element does not specify a style, it is assumed to be "document".'
So the code needs to check if the soi has a style and if not read it from the
binding and if not then set it as "document". This is not a problem in the
WSDLs generated by CXF (as I found out with a HelloWorld test) because it
creates these optional style attributes, but since W3C says people can generate
WSDLs without these (and I ran into one) I think it's worth fixing.
Unless someone disagrees, I'll create a defect for this and contribute a patch.
While reading code and stepping through the debugger to find out where this was
going wrong, I also found that if you use a SOAPMessage instead of a Source
then the following function fails (ignoring the exception) and your
ws-addressing action doesn't get set either- if you have any whitespace after
the soap:body element before your first payload element:
private String getPayloadElementName(SOAPMessage soapMessage) {
try {
SOAPElement element =
(SOAPElement)soapMessage.getSOAPBody().getChildElements().next();
return new QName(element.getNamespaceURI(),
element.getLocalName()).toString();
} catch (Exception e) {
//ignore
}
return null;
}
This fails because the .next() call at the end gets a text node instead of an
element object so the cast fails. So inexplicably your ws-addressing action
header doesn't get set in this case either. Unless someone disagrees, I'll
create a defect for this as well and contribute a patch.
Thanks so much for your help! I wouldn't have gone looking and found this out
without knowing it *should* work.
Jesse
-Original Message-
From: Jesse Pangburn
Sent: Wednesday, August 17, 2011 11:17 AM
To: 'Daniel Kulp'; users@cxf.apache.org
Subject: RE: dispatch api with ws-addressing
Hi Dan,
Thanks for the suggestion, I'm trying to figure out one of those cases. I
changed the code to this to try a DOMSource instead:
Dispatch disp = service.createDispatch(new
QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"), Source.class,
Service.Mode.PAYLOAD, new AddressingFeature());
InputStream is =
IBServer.class.getResourceAsStream("RegistryQuery.xml");
Document doc = XMLUtils.parse(is);
DOMSource reqMsg = new DOMSource(doc);
Source response = disp.invoke(reqMsg);
DOMSource also sent the same wrong action header. I see that I get back a
StaxSource (CXF StaxSource, not javax StAXSource) in this case so I tried using
that as the input next:
Dispatch disp = service.createDispatch(new
QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"), Source.class,
Service.Mode.PAYLOAD, new AddressingFeature());
InputStream is =
IBServer.class.getResourceAsStream("RegistryQuery.xml");
XMLInputFactory xmlInputFactory = XMLInputFactory.newFactory();
XMLStreamReader xmlStreamReader =
xmlInputFactory.createXMLStreamReader(is, "UTF-8");
StaxSource staxSource = new StaxSource(xmlStreamReader);
Source response = disp.invoke(staxSource);
StaxSource also sent the same wrong action header. I also tried SAXSource:
InputSource inputSource = new InputSource(is);
SAXSource saxSource = new SAXSource(inputSource);
Source response = disp.invoke(saxSource);
And lastly I tried javax's StAXSource:
//StaxSou
RE: security action for client
Hi, The default actions are defined in WSHandlerConstants (the source code would help) Also, see this page: http://cxf.apache.org/docs/ws-security.html Which one to use depends on the security chosen by the service. If there is no policy config in the wsdl, I think you should know from the provider for the one that is supported by the service. -Vinay -Original Message- From: fachhoch [mailto:fachh...@gmail.com] Sent: Wednesday, August 17, 2011 3:49 PM To: users@cxf.apache.org Subject: Re: security action for client Please help me , what are the possible values for action and how to decide what to use ? Please tell me the value of action should is it something service provider has to give me? I have no clue what to use there , please advice me. Appreciate help. -- View this message in context: http://cxf.547215.n5.nabble.com/security-action-for-client-tp4705127p4709607.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: security action for client
Please help me , what are the possible values for action and how to decide what to use ? Please tell me the value of action should is it something service provider has to give me? I have no clue what to use there , please advice me. Appreciate help. -- View this message in context: http://cxf.547215.n5.nabble.com/security-action-for-client-tp4705127p4709607.html Sent from the cxf-user mailing list archive at Nabble.com.
AsymmetricBinding
Hi Oliver,
Following the jaxws-ws-trust example for WS-SecurityPolicy with STS, I was able
to configure the STSClient bean in the jaxws:client bean configuration. The
example shows SymmetricBinding. Is there an example for the case where the
outgoing request needs AsymmetricBinding ?
Thanks
Vinay
-Original Message-
From: Oliver Wulff [mailto:owu...@talend.com]
Sent: Saturday, August 13, 2011 8:31 AM
To: users@cxf.apache.org
Subject: RE: ws-security.sts.client
Hi Vinay
There is also a configuration way to enforce the issuance of a security token
from the STS and attach it to the outgoing request automatically. All you need
is the STSClient bean in the jaxws:client bean configuration as well as the
WS-SecurityPolicy in the WSDL or referenced externally (see policy options
here: http://cxf.apache.org/docs/how-it-works.html)
Talend has enriched the CXF distribution with additional examples. You can
download the examples for CXF (Talend Service Factory) here:
http://www.talend.com/download.php#SF
Have a look to the following examples (check the readme)
jaxws-ws-trust: Illustrates teh usage of WS-SecurityPolicy with an STS (your
case)
jaxws-ws-secpol : Illustrates the usage of WS-SecurityPolicy without an STS
You find there also a link for a manual which describes how to configure CXF
for WS-Trust.
If you still prefer to enforce it in your code, have a look to the CXF class
IssuedTokenInterceptorProvider which implements the communication with the STS:
http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/interceptors/IssuedTokenInterceptorProvider.java?view=markup
HTH
Thanks
Oli
-Original Message-
From: Penmatsa, Vinay [mailto:vinay.penma...@sap.com]
Sent: Freitag, 12. August 2011 22:41
To: users@cxf.apache.org
Subject: ws-security.sts.client
Hello,
I am able to get security token from STS, but now I want to use in the service
call. The problem is for STSClient I'm using spring configuration partially.
I have generated the web service client. How can I combine these two?
I tried to do:
((BindingProvider)port).getRequestContext().put("ws-security.sts.client",
stsClient);
But this seems to have no effect.
-Vinay
RE: dispatch api with ws-addressing
Hi Dan,
Thanks for the suggestion, I'm trying to figure out one of those cases. I
changed the code to this to try a DOMSource instead:
Dispatch disp = service.createDispatch(new
QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"), Source.class,
Service.Mode.PAYLOAD, new AddressingFeature());
InputStream is =
IBServer.class.getResourceAsStream("RegistryQuery.xml");
Document doc = XMLUtils.parse(is);
DOMSource reqMsg = new DOMSource(doc);
Source response = disp.invoke(reqMsg);
DOMSource also sent the same wrong action header. I see that I get back a
StaxSource (CXF StaxSource, not javax StAXSource) in this case so I tried using
that as the input next:
Dispatch disp = service.createDispatch(new
QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"), Source.class,
Service.Mode.PAYLOAD, new AddressingFeature());
InputStream is =
IBServer.class.getResourceAsStream("RegistryQuery.xml");
XMLInputFactory xmlInputFactory = XMLInputFactory.newFactory();
XMLStreamReader xmlStreamReader =
xmlInputFactory.createXMLStreamReader(is, "UTF-8");
StaxSource staxSource = new StaxSource(xmlStreamReader);
Source response = disp.invoke(staxSource);
StaxSource also sent the same wrong action header. I also tried SAXSource:
InputSource inputSource = new InputSource(is);
SAXSource saxSource = new SAXSource(inputSource);
Source response = disp.invoke(saxSource);
And lastly I tried javax's StAXSource:
//StaxSource staxSource = new StaxSource(xmlStreamReader);
StAXSource staxSource = new StAXSource(xmlStreamReader);
Source response = disp.invoke(staxSource);
I thought maybe one of these was one of the cases you referred to, but assume I
misunderstood or am doing something else wrong. Or maybe this only works in
soap 1.1 wsdls or something?
Thanks,
Jesse
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Wednesday, August 17, 2011 10:29 AM
To: users@cxf.apache.org
Cc: Jesse Pangburn
Subject: Re: dispatch api with ws-addressing
On Wednesday, August 17, 2011 12:15:53 PM Jesse Pangburn wrote:
> Hi,
> Thanks for the suggestion, that will work. I was hoping there was some way
> for CXF to do it automatically from the WSDL and the message body, but this
> manual step is at least simple and makes sense.
In SOME cases it can, but I'm not sure if StreamSource is one of them.
Another option is:
disp.getRequestContext().put(MessageContext.WSDL_OPERATION,
new QName(ns, "myOperation")
which will tell CXF what operation that dispatch is mapped to.
One note: you may want to switch from StreamSource to just "Source" if
possible. StreamSource is really the worse of the possible source types from
a performance standpoint. On the incoming side, we pretty much suck the
message into a byte[] or file and re-wrapper that with a new parser. Kind of
crappy. If you do Provider, you would likely get a subclass of
SAXSource which would allow us to maintain some level of streaming.
Dan
>
> Thank you,
> Jesse
>
> -Original Message-
> From: Aki Yoshida [mailto:elak...@googlemail.com]
> Sent: Wednesday, August 17, 2011 2:09 AM
> To: users@cxf.apache.org
> Subject: Re: dispatch api with ws-addressing
>
> Hi,
> you need to set the soap action in the dispatch client's request context.
> In your case, you need to add the following line:
>
> disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
> "urn:ihe:iti:2007:RegistryStoredQuery") ;
>
> Regards, aki
>
> 2011/8/17 Jesse Pangburn :
> > Hi,
> > I'm trying to use the dispatch API and while I can make the service call
> > ok, the ws-address "action" header is wrong. Here's my code: URL
> > wsdlURL = new
> > URL("file:/home/jpangburn/Desktop/IHE/XDSb.Support.Materials.v9/wsdl/XD
> > S.b_DocumentRegistry.wsdl"); Service service = Service.create(wsdlURL,
> > new QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Service"));
> > Dispatch disp = service.createDispatch(new
> > QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"),
> > StreamSource.class, Service.Mode.PAYLOAD, new AddressingFeature());
> > InputStream is =
> > IBServer.class.getResourceAsStream("RegistryQuery.xml"); StreamSource
> > request = new StreamSource(is);
> > StreamSource response = disp.invoke(request);
> >
> > Basically, I try to create a service from a WSDL with the service QName,
> > then create a Dispatch from the port's QName while passing "new
> > AddressingFeature()" to turn on WS-Addressing. The action header comes
> > out like this: > xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/jaxw
> > s/dispatch/DocumentRegistry_PortType/InvokeRequest
> >
> > This is wrong because the SOAP12 binding's operation has the following:
> >
> >
> > So the header should be:
> > > xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryS
> > t
Re: dispatch api with ws-addressing
On Wednesday, August 17, 2011 12:15:53 PM Jesse Pangburn wrote:
> Hi,
> Thanks for the suggestion, that will work. I was hoping there was some way
> for CXF to do it automatically from the WSDL and the message body, but this
> manual step is at least simple and makes sense.
In SOME cases it can, but I'm not sure if StreamSource is one of them.
Another option is:
disp.getRequestContext().put(MessageContext.WSDL_OPERATION,
new QName(ns, "myOperation")
which will tell CXF what operation that dispatch is mapped to.
One note: you may want to switch from StreamSource to just "Source" if
possible. StreamSource is really the worse of the possible source types from
a performance standpoint. On the incoming side, we pretty much suck the
message into a byte[] or file and re-wrapper that with a new parser. Kind of
crappy. If you do Provider, you would likely get a subclass of
SAXSource which would allow us to maintain some level of streaming.
Dan
>
> Thank you,
> Jesse
>
> -Original Message-
> From: Aki Yoshida [mailto:elak...@googlemail.com]
> Sent: Wednesday, August 17, 2011 2:09 AM
> To: users@cxf.apache.org
> Subject: Re: dispatch api with ws-addressing
>
> Hi,
> you need to set the soap action in the dispatch client's request context.
> In your case, you need to add the following line:
>
> disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
> "urn:ihe:iti:2007:RegistryStoredQuery") ;
>
> Regards, aki
>
> 2011/8/17 Jesse Pangburn :
> > Hi,
> > I'm trying to use the dispatch API and while I can make the service call
> > ok, the ws-address "action" header is wrong. Here's my code: URL
> > wsdlURL = new
> > URL("file:/home/jpangburn/Desktop/IHE/XDSb.Support.Materials.v9/wsdl/XD
> > S.b_DocumentRegistry.wsdl"); Service service = Service.create(wsdlURL,
> > new QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Service"));
> > Dispatch disp = service.createDispatch(new
> > QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"),
> > StreamSource.class, Service.Mode.PAYLOAD, new AddressingFeature());
> > InputStream is =
> > IBServer.class.getResourceAsStream("RegistryQuery.xml"); StreamSource
> > request = new StreamSource(is);
> > StreamSource response = disp.invoke(request);
> >
> > Basically, I try to create a service from a WSDL with the service QName,
> > then create a Dispatch from the port's QName while passing "new
> > AddressingFeature()" to turn on WS-Addressing. The action header comes
> > out like this: > xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/jaxw
> > s/dispatch/DocumentRegistry_PortType/InvokeRequest
> >
> > This is wrong because the SOAP12 binding's operation has the following:
> >
> >
> > So the header should be:
> > > xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryS
> > toredQuery
> >
> > All I can guess is that the Dispatch API doesn't know which operation
> > I'm calling so it makes up this generic action header for the port
> > instead of looking at the message I'm sending, determining the
> > operation called, and grabbing the correct soap action to use in the
> > action header. Am I doing something wrong or is this a limitation in
> > the Dispatch API's support for WS-Addressing?
> >
> > Thanks,
> > Jesse
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
RE: dispatch api with ws-addressing
Hi,
Thanks for the suggestion, that will work. I was hoping there was some way for
CXF to do it automatically from the WSDL and the message body, but this manual
step is at least simple and makes sense.
Thank you,
Jesse
-Original Message-
From: Aki Yoshida [mailto:elak...@googlemail.com]
Sent: Wednesday, August 17, 2011 2:09 AM
To: users@cxf.apache.org
Subject: Re: dispatch api with ws-addressing
Hi,
you need to set the soap action in the dispatch client's request context.
In your case, you need to add the following line:
disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
"urn:ihe:iti:2007:RegistryStoredQuery") ;
Regards, aki
2011/8/17 Jesse Pangburn :
> Hi,
> I'm trying to use the dispatch API and while I can make the service call ok,
> the ws-address "action" header is wrong. Here's my code:
> URL wsdlURL = new
> URL("file:/home/jpangburn/Desktop/IHE/XDSb.Support.Materials.v9/wsdl/XDS.b_DocumentRegistry.wsdl");
> Service service = Service.create(wsdlURL, new
> QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Service"));
> Dispatch disp = service.createDispatch(new
> QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"),
> StreamSource.class, Service.Mode.PAYLOAD, new AddressingFeature());
> InputStream is =
> IBServer.class.getResourceAsStream("RegistryQuery.xml");
> StreamSource request = new StreamSource(is);
> StreamSource response = disp.invoke(request);
>
> Basically, I try to create a service from a WSDL with the service QName, then
> create a Dispatch from the port's QName while passing "new
> AddressingFeature()" to turn on WS-Addressing. The action header comes out
> like this:
> xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/jaxws/dispatch/DocumentRegistry_PortType/InvokeRequest
>
> This is wrong because the SOAP12 binding's operation has the following:
>
>
> So the header should be:
> xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
>
> All I can guess is that the Dispatch API doesn't know which operation I'm
> calling so it makes up this generic action header for the port instead of
> looking at the message I'm sending, determining the operation called, and
> grabbing the correct soap action to use in the action header. Am I doing
> something wrong or is this a limitation in the Dispatch API's support for
> WS-Addressing?
>
> Thanks,
> Jesse
>
Re: A question about CXF Client Transports
On Wednesday, August 17, 2011 2:41:05 AM GerryChenStarNet wrote: > Hi everyone! > > I have a question of CXF Client Transports.Can I replace the HTTPConduit of > Client with other HTTPConduit? Sure. You can pretty much always grab the HTTPConduitFactory out of the ConduitInitiatorManager and either wrap it or replace it or anything like that. > For example,I have developed a Endpoint in the server. It used to offer the > service for Client A.Now I want to insert another client(I say it Client B) > to the Server And the Client B use the HTTPConduit of Server. > > I think you can say the requestment is strange.But it is real my request. > Because the principle of TR069 protocol ask to do it. Well, if it's a different protocol, would it make sense to just develop a completely new transport conduit and register that with a different uri scheme? Leave the existing HTTP stuff as is, but create a new transport for this. Dan > > So someone have some sample on replacing the HTTPConduit of Client with > other HTTPConduit. > I would appreciate it if someone can give me some advice. Thanks a lot. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/A-question-about-CXF-Client-Transports-tp47 > 07468p4707468.html Sent from the cxf-user mailing list archive at > Nabble.com. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: wsp:policy client
> My client code is:
>
> ClassPathXmlApplicationContext context = new
> ClassPathXmlApplicationContext(new String[] { "cxf-client.xml" });
> QueryServicePortType port = context.getBeanFactory().getBean("utClient");
> port.search("query");
>
> What should I do to get the UsernameToken policy in the wsdl working? Sorry,
> the examples I find on the web are confusing.
That should be all that you need to do PROVIDING you have all the required CXF
jars for that. That would include the cxf-rt-ws-policy, cxf-rt-ws-addr, and
cxf-rt-ws-security.
Dan
On Wednesday, August 17, 2011 9:40:08 AM Penmatsa, Vinay wrote:
> Hi,
> I have the wsdl for a service from which I generated the client stubs. I
> have the following configuration:
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:http="http://cxf.apache.org/transports/http/configuration";
> xmlns:jaxws="http://cxf.apache.org/jaxws";
> xmlns:cxf="http://cxf.apache.org/core";
> xmlns:p="http://cxf.apache.org/policy";
> xmlns:sec="http://cxf.apache.org/configuration/security";
> xsi:schemaLocation=" http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
> http://cxf.apache.org/transports/http/configuration
> http://cxf.apache.org/schemas/configuration/http-conf.xsd
> http://cxf.apache.org/configuration/security
> http://cxf.apache.org/schemas/configuration/security.xsd
> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> http://cxf.apache.org/policy http://cxf.apache.org/schemas/policy.xsd";>
>
> xmlns:ns1="http://webservice.ns.com";
> id="utClient"
> serviceClass="com.ns.webservice.QueryServicePortType"
> serviceName="ns1:QueryServiceService"
> endpointName="ns1:QueryServicePortSoap11"
> address="http://localhost:9101/services/Soap11Endpoint";
>
>
>
>
>
>value="com.cxftest.client.ClientPasswordCallback"/>
>
>
>
>
>
> My client code is:
>
> ClassPathXmlApplicationContext context = new
> ClassPathXmlApplicationContext(new String[] { "cxf-client.xml" });
> QueryServicePortType port = context.getBeanFactory().getBean("utClient");
> port.search("query");
>
> What should I do to get the UsernameToken policy in the wsdl working? Sorry,
> the examples I find on the web are confusing.
>
>
> Thanks
> Vinay
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: Schema validation is not validating elements from SoapHeader
Is it a bug that CXF is not validating the headers or is it working this way by design? If I look into ReadHeadersInterceptor, the CheckClosingTagsInterceptor is added to the interceptor's chain but when the message is handled there the XMLStreamReader is already pointing to the Body. Therefore the Header is not taken into account for the validation. -- View this message in context: http://cxf.547215.n5.nabble.com/Schema-validation-is-not-validating-elements-from-SoapHeader-tp4705565p4709028.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: SwA and CXF
On Wednesday, August 17, 2011 7:52:29 AM jamesnmullen wrote: > I have written a Java first web service, one of the methods needs to return > an audio file. > > The consumer on this web service only supports SwA (soap with attachments), > I am struggling to get the wsdl to include the necessary mime:part elements > so that the audio files is sent as an attachment and not in the SOAP Body > which is what happens at the moment. > > I cannot see an obvious way when writing Java first to say I want my > response to be mime multipart. Any clues on how to achieve this? With Java first, I'm not sure there is a way with SwA. Anything modern would use MTOM for this type of case and not SwA. You can TRY annotating the param/return with @XmlAttachmentRef, but I'm not really sure what that would do. I don't think that will make it a true SwA, but it might be enough to get it into a form that is acceptable. The best bet is to get the wsdl working with the mime things and and more or less start from an interface generated from that and use that wsdl at deploy time. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Making async interfaces manually with annotations etc?
On Wednesday, August 17, 2011 4:17:58 PM Kent Närling wrote:
> I tried ad-hoc and just wrote the interface myself as:
>
> @WebService
>
> public interface MyService
>
> {
>
> @WebMethod(operationName = "doSomething")
>
> Future doSomething(
>
> @WebParam(name = "someParam") String someParam,
> AsyncHandler asyncHandler);
>
> }
> But with this I just god the error : "Could not find wsdl:binding operation
> info for web method doSomething"
>
> So I guess this means I would have to annotate some binding information? or
> is this impossible to do with annotations?
You ALWAYS have to have the non-async versions there. Thus, put your
original method signature in there. You can then optionally add the async
versions as needed and only for the methods you need.
Dan
>
> On 17 August 2011 10:23, Kent Närling wrote:
> > Hi!
> >
> > We declare our SOAP interfaces in java and then build the WSDL:s from
> > the
> > java code since 99% of our clients are in java and to make it most
> > convenient for them we have decided to follow this path.
> >
> > eg we might have a sample service declared like:
> >
> > @WebService
> >
> > public interface MyService
> >
> > {
> >
> > @WebMethod(operationName = "doSomething")
> >
> > DoSomethingResult doSomething(
> >
> > @WebParam(name = "someParam") String someParam);
> >
> > }
> >
> >
> > Now, we could like to be able to call this using the async way with
> > callbacks, is there some way we can declare this manually with
> > annotations? (ie without generating the code from wsdl)
> >
> > And would it then be possible to JUST declare the callback variations,
> > since we know we won't use the polling approach etc?
> >
> > Thanks
> > /Kent
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Resetting Service URL in WSDL
Hi, I have a service binding provider based on my WSDL. Now, after I start the endpoint, I want to use the Endpoint and reset the service URLs in the WSDL. Is this possible in CXF 2.3.x? If so how? Thanks, Anil
SwA and CXF
I have written a Java first web service, one of the methods needs to return an audio file. The consumer on this web service only supports SwA (soap with attachments), I am struggling to get the wsdl to include the necessary mime:part elements so that the audio files is sent as an attachment and not in the SOAP Body which is what happens at the moment. I cannot see an obvious way when writing Java first to say I want my response to be mime multipart. Any clues on how to achieve this? Thanks, James -- View this message in context: http://cxf.547215.n5.nabble.com/SwA-and-CXF-tp4708539p4708539.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Making async interfaces manually with annotations etc?
I tried ad-hoc and just wrote the interface myself as:
@WebService
public interface MyService
{
@WebMethod(operationName = "doSomething")
Future doSomething(
@WebParam(name = "someParam") String someParam,
AsyncHandler asyncHandler);
}
But with this I just god the error : "Could not find wsdl:binding operation
info for web method doSomething"
So I guess this means I would have to annotate some binding information? or
is this impossible to do with annotations?
On 17 August 2011 10:23, Kent Närling wrote:
> Hi!
>
> We declare our SOAP interfaces in java and then build the WSDL:s from the
> java code since 99% of our clients are in java and to make it most
> convenient for them we have decided to follow this path.
>
> eg we might have a sample service declared like:
>
> @WebService
>
> public interface MyService
>
> {
>
> @WebMethod(operationName = "doSomething")
>
> DoSomethingResult doSomething(
>
> @WebParam(name = "someParam") String someParam);
>
> }
>
>
> Now, we could like to be able to call this using the async way with
> callbacks, is there some way we can declare this manually with annotations?
> (ie without generating the code from wsdl)
>
> And would it then be possible to JUST declare the callback variations,
> since we know we won't use the polling approach etc?
>
> Thanks
> /Kent
>
wsp:policy client
Hi,
I have the wsdl for a service from which I generated the client stubs. I have
the following configuration:
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:http="http://cxf.apache.org/transports/http/configuration";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xmlns:cxf="http://cxf.apache.org/core";
xmlns:p="http://cxf.apache.org/policy";
xmlns:sec="http://cxf.apache.org/configuration/security";
xsi:schemaLocation=" http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/policy http://cxf.apache.org/schemas/policy.xsd";>
http://webservice.ns.com";
id="utClient"
serviceClass="com.ns.webservice.QueryServicePortType"
serviceName="ns1:QueryServiceService"
endpointName="ns1:QueryServicePortSoap11"
address="http://localhost:9101/services/Soap11Endpoint";
>
My client code is:
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new
String[] { "cxf-client.xml" });
QueryServicePortType port = context.getBeanFactory().getBean("utClient");
port.search("query");
What should I do to get the UsernameToken policy in the wsdl working? Sorry,
the examples I find on the web are confusing.
Thanks
Vinay
Re: A question about CXF Client Transports
Hi Gerry, As per my understanding Conduit is generally used by client/consumer and Destination by server to respond to the request that is to be consumed by consumer. Are you trying to say you have a Endpoint implementation on Server side which acts like a client for some other service? If this is the case and both Client A and Client B(your old and new client impl.) are using HTTP there shouldn't any need to change the conduit implementation. Can you clarify the scenario bit more ? Regards, Ulhas Bhole On 17 Aug 2011, at 10:41, GerryChenStarNet wrote: > Hi everyone! > > I have a question of CXF Client Transports.Can I replace the HTTPConduit of > Client with other HTTPConduit? > > For example,I have developed a Endpoint in the server. It used to offer the > service for Client A.Now I want to insert another client(I say it Client B) > to the Server And the Client B use the HTTPConduit of Server. > > I think you can say the requestment is strange.But it is real my request. > Because the principle of TR069 protocol ask to do it. > > So someone have some sample on replacing the HTTPConduit of Client with > other HTTPConduit. > I would appreciate it if someone can give me some advice. Thanks a lot. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/A-question-about-CXF-Client-Transports-tp4707468p4707468.html > Sent from the cxf-user mailing list archive at Nabble.com.
Re: Convert Byte Array to Base64Binary
Hi, Thanks a lot for providing different ways to enabling or disabling the MTOM. I could able to have a inline Base64Binary by disabling the MTOM and increasing the MTOM threshold(1024). I understood that MTOM will be enabled for attachment when threshold is crossed, even through MTOM is disabled. Please correct me if i'm wrong. Is there any way to configure through spring client configuration? I don't want to make this changes in wsdl or in code as my code may run on Websphere v6.1 with web services feature pack installed. I've tried with following configuration and I named file as cxf.xml, it is picked up by cxf but no effect on the configuration. It still converts to XOP. Please help me? http://www.springframework.org/schema/beans"; xmlns:jaxws="http://cxf.apache.org/jaxws"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";> - Regards, William Rovinson -- View this message in context: http://cxf.547215.n5.nabble.com/Convert-Byte-Array-to-Base64Binary-tp4696903p4707011.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: dispatch api with ws-addressing
Hi,
you need to set the soap action in the dispatch client's request context.
In your case, you need to add the following line:
disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
"urn:ihe:iti:2007:RegistryStoredQuery") ;
Regards, aki
2011/8/17 Jesse Pangburn :
> Hi,
> I'm trying to use the dispatch API and while I can make the service call ok,
> the ws-address "action" header is wrong. Here's my code:
> URL wsdlURL = new
> URL("file:/home/jpangburn/Desktop/IHE/XDSb.Support.Materials.v9/wsdl/XDS.b_DocumentRegistry.wsdl");
> Service service = Service.create(wsdlURL, new
> QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Service"));
> Dispatch disp = service.createDispatch(new
> QName("urn:ihe:iti:xds-b:2007", "DocumentRegistry_Port_Soap12"),
> StreamSource.class, Service.Mode.PAYLOAD, new AddressingFeature());
> InputStream is =
> IBServer.class.getResourceAsStream("RegistryQuery.xml");
> StreamSource request = new StreamSource(is);
> StreamSource response = disp.invoke(request);
>
> Basically, I try to create a service from a WSDL with the service QName, then
> create a Dispatch from the port's QName while passing "new
> AddressingFeature()" to turn on WS-Addressing. The action header comes out
> like this:
> xmlns="http://www.w3.org/2005/08/addressing";>http://cxf.apache.org/jaxws/dispatch/DocumentRegistry_PortType/InvokeRequest
>
> This is wrong because the SOAP12 binding's operation has the following:
>
>
> So the header should be:
> xmlns="http://www.w3.org/2005/08/addressing";>urn:ihe:iti:2007:RegistryStoredQuery
>
> All I can guess is that the Dispatch API doesn't know which operation I'm
> calling so it makes up this generic action header for the port instead of
> looking at the message I'm sending, determining the operation called, and
> grabbing the correct soap action to use in the action header. Am I doing
> something wrong or is this a limitation in the Dispatch API's support for
> WS-Addressing?
>
> Thanks,
> Jesse
>
Making async interfaces manually with annotations etc?
Hi!
We declare our SOAP interfaces in java and then build the WSDL:s from the
java code since 99% of our clients are in java and to make it most
convenient for them we have decided to follow this path.
eg we might have a sample service declared like:
@WebService
public interface MyService
{
@WebMethod(operationName = "doSomething")
DoSomethingResult doSomething(
@WebParam(name = "someParam") String someParam);
}
Now, we could like to be able to call this using the async way with
callbacks, is there some way we can declare this manually with annotations?
(ie without generating the code from wsdl)
And would it then be possible to JUST declare the callback variations, since
we know we won't use the polling approach etc?
Thanks
/Kent
