Href attribute support in soap envelope body
Hi all,
I have a problem when calling an Apache CXF Web service (CXF version is
2.0.4) running under Apache Tomcat 6 from a Delphi client program. The
third parameter JobParamBean that I receive in my Web service on
Tomcat is always null but there is no exception or any other hint in the
Tomcat logs. The parameter is a simple JavaBean class (uses getters and
setters for all properties and implements serializable). Moreover, the
problem does not appear when calling the same Web service from a Java
client. This is my Web service:
@WebService(name=JobService, targetNamespace=http://annuaire.ciss.lu;)
@SOAPBinding(style=Style.RPC)
public interface JobService {
@WebMethod(operationName=ExecuteJob)
@WebResult(name=JobParamsOut)
public String[] executeJob(@WebParam(name=JobName) String jobName,
@WebParam(name=JobParamsIn) String[] input,
@WebParam(name=JobParamBean) JobServiceParam param) throws
ServiceException;
}
When calling this web service from the Delphi application (using the
latest available HTTPRIO component and WSDL importer), the corresponding
generated SOAP request produces null as JobParamBean parameter:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=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/;
SOAP-ENV:Body
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:NS2=http://annuaire.ciss.lu;
NS1:ExecuteJob xmlns:NS1=http://annuaire.ciss.lu;
JobName xsi:type=xsd:stringTestFromDelphi/JobName
JobParamsIn xsi:type=SOAP-ENC:Array
SOAP-ENC:arrayType=xsd:string[2]
itemvalueDelphi1/item
itemvalueDelphi2/item
/JobParamsIn
JobParamBean href=#1 /
/NS1:ExecuteJob
NS2:JobServiceParamType id=1
xsi:type=NS2:JobServiceParamType
key xsi:type=xsd:stringparamkey/key
value xsi:type=xsd:stringparamval/value
/NS2:JobServiceParamType
/SOAP-ENV:Body
/SOAP-ENV:Envelope
I tried to call the same web service from Java (also using Apache CXF
2.0.4) and the generated SOAP request correctly creates a JobParamBean
instance:
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body
ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu;
JobNameTestFromJava/JobName
JobParamsIn
itemvalueJava1/item
itemvalueJava2/item
/JobParamsIn
JobParamBean
keykeyJava/key
value
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:ns3=http://www.w3.org/2001/XMLSchema;
xsi:type=ns3:int
1
/value
/JobParamBean
/ns1:ExecuteJob
/soap:Body
/soap:Envelope
I noticed that the Delphi SOAP request uses a reference for the third
parameter (href=#1) but the Java SOAP request does not. Is it possible
that CXF doesn't support this kind of references? Is there a workaround
in CXF to support the request or perhaps in Delphi to suppress the use
of the reference?
Thanks in advance for any comments on this issue.
Best regards,
Pierre Post
Href attribute support in soap envelope body
Hi all,
I have a problem when calling an Apache CXF Web service (CXF version is
2.0.4) running under Apache Tomcat 6 from a Delphi client program. The
third parameter JobParamBean that I receive in my Web service on
Tomcat is always null but there is no exception or any other hint in the
Tomcat logs. The parameter is a simple JavaBean class (uses getters and
setters for all properties and implements serializable). Moreover, the
problem does not appear when calling the same Web service from a Java
client. This is my Web service:
@WebService(name=JobService, targetNamespace=http://annuaire.ciss.lu;)
@SOAPBinding(style=Style.RPC)
public interface JobService {
@WebMethod(operationName=ExecuteJob)
@WebResult(name=JobParamsOut)
public String[] executeJob(@WebParam(name=JobName) String jobName,
@WebParam(name=JobParamsIn) String[] input,
@WebParam(name=JobParamBean) JobServiceParam param) throws
ServiceException;
}
When calling this web service from the Delphi application (using the
latest available HTTPRIO component and WSDL importer), the corresponding
generated SOAP request is
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=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/;
SOAP-ENV:Body
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:NS2=http://annuaire.ciss.lu;
NS1:ExecuteJob xmlns:NS1=http://annuaire.ciss.lu;
JobName xsi:type=xsd:stringTestFromDelphi/JobName
JobParamsIn xsi:type=SOAP-ENC:Array
SOAP-ENC:arrayType=xsd:string[2]
itemvalueDelphi1/item
itemvalueDelphi2/item
/JobParamsIn
JobParamBean href=#1 /
/NS1:ExecuteJob
NS2:JobServiceParamType id=1
xsi:type=NS2:JobServiceParamType
key xsi:type=xsd:stringparamkey/key
value xsi:type=xsd:stringparamval/value
/NS2:JobServiceParamType
/SOAP-ENV:Body
/SOAP-ENV:Envelope
I tried to call the same web service from Java (also using Apache CXF
2.0.4) and the generated SOAP request is
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body
ns1:ExecuteJob xmlns:ns1=http://annuaire.ciss.lu;
JobNameTestFromJava/JobName
JobParamsIn
itemvalueJava1/item
itemvalueJava2/item
/JobParamsIn
JobParamBean
keykeyJava/key
value
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:ns3=http://www.w3.org/2001/XMLSchema;
xsi:type=ns3:int
1
/value
/JobParamBean
/ns1:ExecuteJob
/soap:Body
/soap:Envelope
I noticed that the Delphi SOAP request uses a reference for the third
parameter (href=#1) but the Java SOAP request does not. Is it possible
that CXF doesn't support this kind of references? Is there a workaround
in CXF to support the request or perhaps in Delphi to suppress the use
of the reference?
Thank you in advance for any comments on this issue.
Best regards,
Pierre Post
Dynamically change interceptors in an interceptor chain?
Hello, Can I program an interceptor in a web service's incoming interceptor chain to dynamically route to another interceptor other than the one predefined in its chain (and ignore all subsequent interceptors in the predefined chain)? In other words, for an interceptor chain A-B-C-D, can I add business logic in interceptor A for it to route to A-E-F-G instead? In particular, I would like to avoid it doing A-E-F-G-B-C-D if I can, i.e., once I reroute, I don't want it to return to the other interceptors in the predefined chain. Thanks, Glen -- View this message in context: http://www.nabble.com/Dynamically-change-interceptors-in-an-interceptor-chain--tp15546687p15546687.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Dynamically change interceptors in an interceptor chain?
Glen, On Monday 18 February 2008, Glen Mazza wrote: Can I program an interceptor in a web service's incoming interceptor chain to dynamically route to another interceptor other than the one predefined in its chain (and ignore all subsequent interceptors in the predefined chain)? Kind of yes. Basically, there are a couple ways to do it. One option is to grab the current InterceptorChain and remove everything you don't want (or comes after your interceptor).I believe you can just get the Iterator from the chain and use the remove methods on that. I think they are implemented.Then add in everything you do want. Another option is to create a whole new chain (you could have chains cached with the PhaseChainCache stuff) with the new stuff you want. In your interceptor, you would pause the current chain (so nothing else would get called later) and then call newChain.processmessage(msg); Dan In other words, for an interceptor chain A-B-C-D, can I add business logic in interceptor A for it to route to A-E-F-G instead? In particular, I would like to avoid it doing A-E-F-G-B-C-D if I can, i.e., once I reroute, I don't want it to return to the other interceptors in the predefined chain. Thanks, Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Servlet.service() for servlet CXFServlet exception
Hi, Thanks for your reply Sergey. I managed to solve the problem, it actually was a JBoss config issue... Now, however, I'm facing new problems deploying my JAX-RS based web service. On accessing /services/, I already find it listed as it should be, but when I try to call the service I get a 500 Server Error in return. From JBoss logs, I found out the exception being raised: INFO: URIParameterInterceptor handle message on path [/workorder/6] with content-type [null] 15:53:15,008 ERROR [[CXFServlet]] Servlet.service() for servlet CXFServlet threw exception java.lang.NullPointerException at org.apache.cxf.transport.ChainInitiationObserver.setExchangeProperties(ChainInitiationObserver.java:93) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:59) at org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:256) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:123) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170) at org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:152) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.criticalsoftware.wow.presentation.CookieFilter.doFilter(CookieFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) Any thoughts on this one? Thanks in advance, Rui Ramos -- View this message in context: http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15546908.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Servlet.service() for servlet CXFServlet exception
Hi It seems to be a lower-level CXF issue, ChainInitiationObserver.java:93 shows this code in my snapshot : exchange.put(Bus.class, bus); which is harmlessPerhaps the fact that a content type is set to null causes the problem. Still it's likely that Endpoint which ChainInitiationObserver deals with has not been set up properly... Is there any chance you can try to run your server using a simple main(), without JBoss involved ? For ex, have a look at BookServerResourceCreatedSpring. It runs a server using a /jaxrs_spring resource folder which has beans.xml, so just update it to refer to your web-app folder and try to get resources from a browser. It will help narrow the problem. Cheers, Sergey - Original Message - From: rm-ramos [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Monday, February 18, 2008 4:03 PM Subject: Re: Servlet.service() for servlet CXFServlet exception Hi, Thanks for your reply Sergey. I managed to solve the problem, it actually was a JBoss config issue... Now, however, I'm facing new problems deploying my JAX-RS based web service. On accessing /services/, I already find it listed as it should be, but when I try to call the service I get a 500 Server Error in return. From JBoss logs, I found out the exception being raised: INFO: URIParameterInterceptor handle message on path [/workorder/6] with content-type [null] 15:53:15,008 ERROR [[CXFServlet]] Servlet.service() for servlet CXFServlet threw exception java.lang.NullPointerException at org.apache.cxf.transport.ChainInitiationObserver.setExchangeProperties(ChainInitiationObserver.java:93) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:59) at org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:256) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:123) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170) at org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:152) at javax.servlet.http.HttpServlet.service(HttpServlet.java:697) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.criticalsoftware.wow.presentation.CookieFilter.doFilter(CookieFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) Any thoughts on this one? Thanks in advance, Rui Ramos -- View this message in context: http://www.nabble.com/JAX-RS-%22No-service-found%22-using-Spring-and-JBoss-tp15461660p15546908.html Sent from the cxf-user mailing list archive at Nabble.com. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Dynamically change interceptors in an interceptor chain?
Glen, No. A fresh interceptor chain is used for each invocation. Thus, during the processing of the message, you can muck with is all you want and would have no impact on future invocations. Dan On Monday 18 February 2008, Glen Mazza wrote: Dan, We're looking at the second option you gave below right now, but I have a question on the first. If I grabbed the InterceptorChain below as you say and modified it, would *all* subsequent web service requests use that modified interceptor chain (which I don't want), or would the business logic in interceptor A be activated each time, letting it decide whether to continue on -B-C-D (the default) or -E-F-G (the alternative as decided by A) (which I do want)? Thanks, Glen PS - please forward your response to CXF-User, I'm operating outside of Nabble right now. On Feb 18, 2008 10:23 AM, Daniel Kulp [EMAIL PROTECTED] wrote: Glen, On Monday 18 February 2008, Glen Mazza wrote: Can I program an interceptor in a web service's incoming interceptor chain to dynamically route to another interceptor other than the one predefined in its chain (and ignore all subsequent interceptors in the predefined chain)? Kind of yes. Basically, there are a couple ways to do it. One option is to grab the current InterceptorChain and remove everything you don't want (or comes after your interceptor).I believe you can just get the Iterator from the chain and use the remove methods on that. I think they are implemented.Then add in everything you do want. Another option is to create a whole new chain (you could have chains cached with the PhaseChainCache stuff) with the new stuff you want. In your interceptor, you would pause the current chain (so nothing else would get called later) and then call newChain.processmessage(msg); Dan In other words, for an interceptor chain A-B-C-D, can I add business logic in interceptor A for it to route to A-E-F-G instead? In particular, I would like to avoid it doing A-E-F-G-B-C-D if I can, i.e., once I reroute, I don't want it to return to the other interceptors in the predefined chain. Thanks, Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Return a SOAP response from the service's incoming interceptor chain?
On Monday 18 February 2008, [EMAIL PROTECTED] wrote: Never mind on this question...thankfully I don't have to do this. It's an interesting question, so I'm going to answer it anyway. :-) If you look at the IN interceptor chain, at the very end of the chain is the OutgoingChainInterceptor. It's job is to construct the outgong chain, setup the out message and then invoke the out chain.If you want, you can easily remove that interceptor from the chain and do much of that work yourself. Or skip much of that work. In your case, you can call message.getExchange().getDestination().getBackChannel() to get the conduit that would be used to send the response back. From that conduit, you should be able to prepare a message (which would set the output stream, then write to the output stream, flush/close, then close the message on the conduit. Those are all things the various out interceptors do, but you should be able to do it yourself fairly easily. Obviously, make sure you pause/abort the current chain to keep the current chain from then calling the OutgoingChainInterceptor. Otherwise, multiple responses could get written out which some transports (like http) don't do very well with. Dan Glen From: Glen Mazza [EMAIL PROTECTED] Date: 2008/02/18 Mon AM 11:57:20 CST To: cxf-user@incubator.apache.org Subject: Return a SOAP response from the service's incoming interceptor chain? Hello, I have another interceptor question. I know this would be a ugly, non-ideal usage of interceptor chains, but let's say from one of the interceptors in the webservice's *incoming* interceptor chain I immediately know what the SOAP response should be--I even have the response in proper SOAP format with a soap:envelope, soap:body etc. What I would like to do is immediately return that SOAP response from the in interceptor back to the client with no further processing--no more of the *in* interceptors, and none of the *out* interceptors. Can I do that within CXF? Thanks, Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Return a SOAP response from the service's incoming interceptor chain?
Never mind on this question...thankfully I don't have to do this. Glen From: Glen Mazza [EMAIL PROTECTED] Date: 2008/02/18 Mon AM 11:57:20 CST To: cxf-user@incubator.apache.org Subject: Return a SOAP response from the service's incoming interceptor chain? Hello, I have another interceptor question. I know this would be a ugly, non-ideal usage of interceptor chains, but let's say from one of the interceptors in the webservice's *incoming* interceptor chain I immediately know what the SOAP response should be--I even have the response in proper SOAP format with a soap:envelope, soap:body etc. What I would like to do is immediately return that SOAP response from the in interceptor back to the client with no further processing--no more of the *in* interceptors, and none of the *out* interceptors. Can I do that within CXF? Thanks, Glen -- View this message in context: http://www.nabble.com/Return-a-SOAP-response-from-the-service%27s-incoming-interceptor-chain--tp15547076p15547076.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS API version change
I've got it mostly finished, but I'm going to add few more tests before supplying a patch Cheers, Sergey - Original Message - From: Sergey Beryozkin [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Friday, February 15, 2008 4:55 PM Subject: JAX-RS API version change Hi Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api. I'm looking into upgrading it to support a latest 0.5 version. There're some changes from 0.4 to 0.5 which would affect users. The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the current JAX-RS applications built on top of CXF : 1. @HttpMethod annotation is no longer supported, instead @GET, @POST, @PUT and @DELETE annotations will be used 2. @UriTemplate is not longer supported, @Path is used instead 3. EntityProvider interface has gone too, instead it has been split into two interfaces, MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both reads and writes, then you'd have to have its class implementing both interfaces. Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers into the right lists itself... Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Empty string namespace mapping with JSON and HTTP Post
As did I. Sent a patch: http://jira.codehaus.org/browse/JETTISON-34 Harri mgibble wrote: Actually, I believe the link you sent illustrates what I am expecting to see, but am not: -- View this message in context: http://www.nabble.com/Empty-string-namespace-mapping-with-JSON-and-HTTP-Post-tp13979132p15547593.html Sent from the cxf-user mailing list archive at Nabble.com.
