RE: Issues with JSON based Service and Jettison
-Original Message-
From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
Sent: 2008年1月18日 5:38
To: cxf-user@incubator.apache.org
Subject: RE: Issues with JSON based Service and Jettison
Jervis, I actually got it working end to end - once I added the namespace as a
property in my jettison settings of my beans.xml - it works quite nicely and
even deals with my wrapper/anytypes.
Out of curiousity, there have been some oblique mentions here and there of
having the incoming JSON parsed out into mapped variables, eg I have a
JSON object named message with message: { id:1, name=foo} and a web
service that takes id and name as params and outputs JSON - it seems from
your previous emails this is not possible? That only the jettison system will
work with one argumenet? Is this true of jax-rs as well?
[Liu, Jervis] Hi Tony, you've got this almost right. When a JSON object comes
in, it is transferred to a XML document first, for example,
{acme.Book:{acme.name:CXF in Action ,acme.id:123 }} is transferred
to an org.w3c.dom.Document of BooknameCXF in
Action/nameid123/id/Book. Then the XML document will be parsed and
mapped to request parameters of the target method following the JAX-WS spec.
Whether or not the XML document of BooknameCXF in
Action/nameid123/id/Book is mapped to a Book object or mapped to two
separate parameters of id and name is depending on doc/lit bare style or
doc/lit wrapped style. The one argument limitation does nothing with Jettison,
it comes from the implementation of CXF HTTP binding. JAX-RS does not have this
limitation, you can have multiple parameters for your resource method, for
example, one parameter mapped from http header, one from URL path variable, one
from Http body. Note the Http body can only be mapped to one parameter. This is
defined by JSR-311 spec.
Thanks again for your guidance - it helped me a lot with the issues I was
having. Once I get things settled, I'll try to write up a workable example
for
inclusion.
-Tony
-Original Message-
From: Liu, Jervis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 10:25 PM
To: cxf-user@incubator.apache.org
Subject: RE: Issues with JSON based Service and Jettison
You got 'Invalid URL/Verb combination. Verb: POST Path: /message'
exception when the combination of Verb: POST and Path: /message did
not find a method from your service. Not sure why though as your service
looks alright. You may want to paste out the initialization information when
your server is starting up, it normally says sth like below:
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method getBook to resource /books/{id} and verb GET
2008-1-17 11:23:08 org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be
http://localhost:9080/xmlwrapped
2008-1-17 11:23:08
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://book.acme.com}BookServiceService from
class org.apache.cxf.customer.book.BookService
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method updateBook to resource /books/{id} and verb PUT
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method getBooks to resource /books and verb GET
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method getAnotherBook to resource /books/another/{id}
and verb GET
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method addBook to resource /books and verb POST
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method getBook to resource /books/{id} and verb GET
2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
INFO: Mapping method deleteBook to resource /books/{id} and verb DELETE
2008-1-17 11:23:08 org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://localhost:9080/json
-Original Message-
From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
Sent: 2008年1月17日 0:05
To: cxf-user@incubator.apache.org
Subject: RE: Issues with JSON based Service and Jettison
So after some thought and tweaking I adjusted my JSON service, but I am
getting the 'Invalid URL/Verb combination. Verb: POST Path: /message'
exception.
My service looks like this:
@WebService(targetNamespace = http://com.cbs.bos.ws.json;)
public interface BoardService {
@Post
@HttpResource(location = /message)
public wsResponsewsMessage getMessage(
@WebParam(name = message)wsMessage message);
}
I am using this javascript:
var json = {wsMessage:{messageId:1}};
new Ajax.Request($F('url'), {
asynchronous: false,
method: 'post',
contentType: 'application/json',
postBody:
Re: WSS4J - Protection Order
Hi Fred, Yes, making some changes in WSSecEncrypt, EncryptionAction and SignatureAction to process WSEncryptionPart instance allow us to process Signature over EncryptedData elements. Hence, in the message ReferenceList in Signature element refers to the wsu:id of the right EncryptedData element. I tested it with a sample which Encrypts and then Sign a Timestamp. This helps to process both Action=Signature Encrypt and Action=Encrypt Signature configuration options, when both EncryptParts and SignParts are referring to the same element. In context of WS-Security Policy, thus above change make us support ProtectionOrder - SignBeforeEncrypting and EncryptBeforeSigning. With Regards, Mayank Mayank Mishra wrote: Hi Fred, Yes, sounds interesting. But consider a scenario when I have Sign-Encrypt-Sign or Encrypt-Sign-Encrypt to be done, then the same interceptor need to added twice (before and after the other one). A solution to this will be to see all Actions beforehand and then repeat adding interceptors for repeated Actions accordingly. Also since, we are seeking a generic solution, IMO this will be a bit overhead. Also, each designated WSS4JInterceptors will have their own data structures (cryptos, etc) leading to high memory overhead. The trade-off in the other solution (tweaking SecurityAction, EncryptionAction) is that we have to change WSS4J code. But, a solution to this issue will provide support for ProtectionOrder (SignBeforeEncrypting and EncryptBeforeSigning in WS-Security Policy spec), though not a concern right now. What are you thoughts? With Regards, Mayank Fred Dushin wrote: I see, interesting. In order to do this in a way that does not require a change to CXF, perhaps what you could do is split your encryption and signature actions into 2 separate interceptors, and add a third in between, which peeks at the result of the encryption action (the results object will be on the message), and then programatically configures the WS4JOutInterceptor, which will do the signature action for you. -Fred On Jan 23, 2008, at 12:41 AM, Mayank Mishra wrote: Hi Fred, Yes, you are right. I am talking about the scenario when we have multiple EncryptedData elements and I want to sign only one of them. Yes, I agree XPath would have been much better to handle such scenario. But AFAIK, we can specify parts (WSEncryptionPart) during SignatureAction by initializing part structure with element Id (I guess it is wsu:id, which we can get from map populated during encryptionAction). I am yet to test it. I will let you know about it. With Regards, Mayank Fred Dushin wrote: Hi Mayank, When you say one way to achieve this is to specify the URI of the EncryptedData, do you mean QName, instead of URI? I get the sense from what you are saying that your message may have multiple EncryptedData elements in it, and you want to sign one, but not others. Is that right? If you have only one EncryptedData, then you should be able to direct the WSS4J toolkit to sign it, by specifying the EncryptedData QName, in configuration of the interceptor. Unfortunately, WSS4J does not provide XPath support for protecting (signing/encrypting) message parts, so using QNames is inherently ambiguous. -Fred On Jan 18, 2008, at 2:24 AM, Mayank Mishra wrote: Any reply to this thread will be highly appreciated. Thanking in advance, With Regards, Mayank Mayank Mishra wrote: Hi, Usually we use, Sign and then Encrypt action for any particular xml element. If I want to use Encrypt and then Sign for a particular xml element, then SignatureAction fails to find the xml element. The reason is it has been encrypted and hence corresponding EncryptedData element will be there. One way to achieve this, is to specify, URI of EncryptedData itself in the signature parts. (It should work, though I haven't tested it). But this is not a full proof solution if I want only specific element only to be encrypted and eventually signed. *Is there any mechanism to achieve this?* The only way I can think of achieving this is to maintain a list of wsu:id's of corresponding EncryptedData elements and add URI of them to Signature Parts during .SignatureAction. This may be performed in adding another interceptor which handles the message after encryption has been done. Please let me know your views/suggestions about this. Thanking in advance. :) With Regards, Mayank
SOAPFaultException, maybe a bug in the framework?
I am trying to throw a SOAPFaultException from an handler. Anyway I have some
weird error in what I get back.
I have tried the same code on java 6 without CXF and the handler chain works
differently (with java 1.6 works fine)
This is the handleMessage on my custom SOAPHandler (the way I fill the
SOAPFault is taken from the SUN tutorial):
1) WITH JAVA 6:
public boolean handleMessage(SOAPMessageContext ctx) {
Boolean outboundProperty = (Boolean) ctx
.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
if (!outboundProperty) {
SOAPMessage msg = ctx.getMessage();
SOAPBody body;
try {
body = msg.getSOAPBody();
SOAPFault fault = body.addFault();
QName faultName = new
QName(SOAPConstants.URI_NS_SOAP_ENVELOPE,
Server);
fault.setFaultCode(faultName);
fault.setFaultActor(http://gizmos.com/orders;);
fault.setFaultString(Server not responding);
Detail detail = fault.addDetail();
QName entryName = new
QName(http://gizmos.com/orders/;,
order, PO);
DetailEntry entry =
detail.addDetailEntry(entryName);
entry.addTextNode(Quantity element does not
have a value);
QName entryName2 = new
QName(http://gizmos.com/orders/;,
order, PO);
DetailEntry entry2 =
detail.addDetailEntry(entryName2);
entry2.addTextNode(Incomplete address: no zip
code);
throw new SOAPFaultException(fault);
} catch (SOAPException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
return true;
}
and here is the log of the message sent back to the client. The SOAPFault is
populated correctly.
soapenv:Fault
faultcodesoapenv:Server/faultcode
faultstringServer not responding/faultstring
faultactorhttp://gizmos.com/orders/faultactor
detail
PO:order xmlns:PO=http://gizmos.com/orders/;Quantity element does
not have a value/PO:order
PO:order xmlns:PO=http://gizmos.com/orders/;Incomplete address:
no zip code/PO:order
/detail
/soapenv:Fault
2) WITH CXF + Java 5:
I have the same handler doing the same work. debugging the SOAPFault seems
to be populated correctly:
Anyway logging the answer here is what I get.
soap:Fault
faultcodesoap:Server/faultcode
faultstringServer not responding/faultstring
/soap:Fault
The actor and expecially the details are missing.
I have tried debugging the org.apache.cxf.jaxws.handler.HandlerChainInvoker,
but I was not abel to figure out if there is some error somewhere.
Do you think it is a bug or an hidden error of mine?
Thanks a lot.
Davide
--
View this message in context:
http://www.nabble.com/SOAPFaultException%2C-maybe-a-bug-in-the-framework--tp15269025p15269025.html
Sent from the cxf-user mailing list archive at Nabble.com.
Issue with CXF: Marshalling Error: Error writing request body to server
Hello! I have ran into a serious problem with CXF on the client side. I have tried quite a few things but I am right now quite stuck, and I hope that you guys have any suggestions. The full stacktrace is in this mail. I get the same error both with 2.0.3 and 2.0.4. Can it be an issue with JAXB, I am using jaxb-impl 2.0.5 from the sun-site. The following error is given when I invoke the web service method. SubmitDataService service = new SubmitDataService(); ISubmitData port = service.getSubmitDataPort(); boolean ret = port.submitData(setId, setName, fileName, getData(fileName), list); INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:207) at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:63) at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:84) at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) at $Proxy26.submitData(Unknown Source) at com.pointcarbon.mule.SubmitDataClient.main(SubmitDataClient.java:85) Caused by: javax.xml.bind.MarshalException - with linked exception: [java.io.IOException: Error writing request body to server] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:297) at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:221) at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:70) at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:360) at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:187) ... 10 more Caused by: java.io.IOException: Error writing request body to server at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2261) at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2244) at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:45) at org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:64) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.flushBuffer(UTF8XmlOutput.java:351) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:304) at com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.writeTo(Base64Data.java:263) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:251) at com.sun.xml.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.java:312) at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$PcdataImpl.writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:140) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:214) at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:62) at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:286) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:619) at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:113) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:98) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 14 more Exception in thread Main Thread javax.xml.ws.soap.SOAPFaultException: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:175) at $Proxy26.submitData(Unknown Source) at com.pointcarbon.mule.SubmitDataClient.main(SubmitDataClient.java:85) Caused by:
Deploy my service implementation separately from my security configuration?
Hello, I am working with CXF 2.0.4 with javaFirst/Spring/CXF Servlet. I have the jaxws setup using Timestamp, Signature, and Encypt. I have some customized interceptors and a handler. This is all included in one war file (just like the demos) that I deploy to JBoss (and eventually Websphere). I was wondering if its possible to: - separate out my service implementation as one war file and my security configuration as another war file or - have my service endpoint be external from the same JVM that CXF is under (the internal endpoint is different from the published external endpoint). The goal is to keep the security settings untouchable when further maintenance/enhancements of the service methods goes forward. We don't want to have to worry about the security getting broken once we know that its working correctly. I believe that this is called hardening the security. Any suggestions/readings would really be appreciated.
Fast Infoset
Hi, Has anyone had any luck plugging in the java.net Fast Infoset reference implementation into CXF? I tried doing something like the following: import javax.xml.stream.XMLInputFactory; import javax.xml.stream.XMLOutputFactory; import com.sun.xml.fastinfoset.stax.factory.StAXInputFactory; import com.sun.xml.fastinfoset.stax.factory.StAXOutputFactory; ... // Server setup JaxWsServerFactoryBean serverFactory = new JaxWsServerFactoryBean(); serverFactory.setAddress(http://localhost:12345/MyService;); serverFactory.setServiceClass(MyService.class); serverFactory.setServiceBean(new MyServiceImpl()); MapString,Object properties = new HashMapString,Object(); properties.put(XMLInputFactory.class.getName(), new MyXmlInputFactory()); properties.put(XMLOutputFactory.class.getName(), new MyXmlOutputFactory()); serverFactory.setProperties(properties); serverFactory.create(); // Client setup JaxWsProxyFactoryBean clientFactory = new JaxWsProxyFactoryBean(); clientFactory.setAddress(http://localhost:12345/MyService;); clientFactory.setServiceClass(MyService.class); MapString,Object properties = new HashMapString,Object(); properties.put(XMLInputFactory.class.getName(), new StAXInputFactory()); properties.put(XMLOutputFactory.class.getName(), new StAXOutputFactory()); clientFactory.setProperties(properties); MyService service = (MyService)clientFactory.create(); Unfortunately invoking any methods on client proxy results in the following exception because the Fast Infoset vocabulary has not been setup: Caused by: java.lang.NullPointerException at com.sun.xml.fastinfoset.Encoder.encodeNamespaceAttribute(Encoder.java:558) at com.sun.xml.fastinfoset.stax.StAXDocumentSerializer.encodeTerminationAndCurrentElement(StAXDocumentSerializer.java:581) at com.sun.xml.fastinfoset.stax.StAXDocumentSerializer.writeStartElement(StAXDocumentSerializer.java:215) at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:130) at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76) at org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) ... 2 more Setting up an empty vocabulary on the StAXDocumentSerializer seems to cause an infinite loop in org.apache.cxf.interceptor.WrappedOutInterceptor.handleMessage(). Anyone have any suggestions before I dig much deeper? Thanks, Joel
Re: HttpSession and Endpoints
Chris, That should be fine as long as your SessionManager is properly re-entrant/thread safe. Dan On Sunday 03 February 2008, Chris Campbell wrote: If I understand the code correctly, the HttpConduit holds the session in a private field with no accessor method, and manages the session itself. So I think I have to use an interceptor to set the cookie on the other proxies. My current work around (I think similar to what you suggested) is to turn off the maintainSession on the conduit and have my own SessionManager that an inbound interceptor can access and set when the Set-Cookie comes back from the first request, and an outbound interceptor can access and set the cookie header for any other request, whichever proxy is making the request. So the SessionManager is stateful, but not the interceptors. But the interceptors do call into my application code, is that a bad practice? Willem Jiang wrote: It is not easy to share the http conduit between the different proxy, since you need to hack the HttpTransportFactory and handle theconfiguration of the http conduit. I don't think using the interceptor could resolve the problem that you met. Because when you using the interceptor to hold the first session cookie, you will make the interceptor stateful. We do not want the interceptor be stateful to avoid lock the multi thread calling. My suggestion is We could put the cookie into the message context for application code to access and reset. Then you can get the cookie from the first proxy in your application code and then set cookie to the second proxy to get around it. Thoughts? Willem. Chris Campbell wrote: That would have to be on the client side, correct? I think I would need to have a client side inInterceptor to do that. I tend to load the proxies as needed, is there a way to probe the bus to get any other loaded proxies so that a lazily instantiated proxy can get a previously acquired session cookie from another? Maybe the inInterceptor can just stash away the first session cookie acquired, and an outInterceptor can apply it to any request. Any thoughts as to what the best practice would be? I guess a feature request would be to be able to share an http-conduit between proxies. I kind of think of the http-conduit as an http client, is that bad analogy? Thanks for the insight, definitely narrowing in on a solution. Daniel Kulp wrote: Oh. Yea. That would definitely do it. Good catch. Each client proxy holds it's own conduit and thus the cookie for the session is stored there is unique for each proxy. Most likely, you will need to do some cookie management your self. Grab the protocol headers from the response headers and set them in the request headers for all the proxies. You can use the org.apache.cxf.transport.http.Cookie class to help with the parsing/setting. Dan On Friday 01 February 2008, Chris Campbell wrote: The problem is that I get a different session for different endpoints, maybe its how I set the client up? I do set the client up in java code rather than with xml config, so maybe I am doing something wrong there. Is it possible that each service interface is getting a different http-conduit? Daniel Kulp wrote: On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
WebSecurity error when using Simple Frontend / Aegis binding
Web Security works for my example A, using JAX-WS Frontend / JAXB binding.
If client sets the wrong password, server will return Security processing
failed. to the client.
Now I want to add WebSecurity to another example B, using Simple Frontend /
Aegis binding.
I use the same ServerPasswordCallback ClientPasswordCallback as in example
A.
My xml is like this:
simple:server id=helloWorld serviceClass=demo.spring.HelloWorld
address=/ServerEndPoint
simple:dataBinding
bean class=org.apache.cxf.aegis.databinding.AegisDatabinding /
/simple:dataBinding
simple:serviceBean
bean class=demo.spring.HelloWorldImpl /
/simple:serviceBean
simple:inInterceptors
bean class=org.apache.cxf.binding.soap.saaj.SAAJInInterceptor/
bean class=org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor
property name=properties
!-- constructor-arg --
map
entry key=action value=UsernameToken/
entry key=passwordType
value=PasswordDigest /
entry key=passwordCallbackClass
value=demo.spring.security.ServerPasswordCallback/
/map
!-- constructor-arg --
/property
/bean
/simple:inInterceptors
/simple:server
If client sets the password right, everything is fine. But if client sets
the wrong password,
server tomcat will have the following exception. And because of it, the
client doesn't receive any response,
and the client will have something like
Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
///tomcat CXF server exception
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.interceptor.FaultOutInterceptor.getFaultForClass(FaultOutInterceptor.java:
128)
at
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutInterceptor.java:61)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultCha
inInitiatorObserver.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:224)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:7
3)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
va:256)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
What's working for JAX-WS Frontend / JAXB binding does not work for Simple
Frontend / Aegis binding.
Is there anything wrong with my xml? How to fix it?
--
View this message in context:
http://www.nabble.com/WebSecurity-error-when-using-Simple-Frontend---Aegis-binding-tp15277618p15277618.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXFServlet
Thanks Willem, This is a super tuesday, it works ;-) Cheers Guillaume
Query About Request Context
Hi, So far I had an idea that request context is put in thread local but I realized it is not. Why the request context is not threadlocal ? If I want to send multiple client requests and each request having different JMS header using same BindingProvider instance then do I need to synchronize the context or not ? I think now it needs to synchronized else it is overwritten by subsequent calls. Can anyone shed a light on this. Regards, Santosh -- View this message in context: http://www.nabble.com/Query-About-Request-Context-tp15282233p15282233.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Query About Request Context
See this:
public class JaxWsClientProxy extends org.apache.cxf.frontend.ClientProxy
implements
InvocationHandler, BindingProvider {
private static final Logger LOG =
LogUtils.getL7dLogger(JaxWsClientProxy.class);
protected MapString, Object requestContext = new
ConcurrentHashMapString, Object();
protected ThreadLocal MapString, Object responseContext =
new ThreadLocalMapString, Object();
Anybody can tell me why responseContext is threadlocal but requestContext
is not? That means BindingProvider is not thread-safe!
Is it a bug?
--
View this message in context:
http://www.nabble.com/Query-About-Request-Context-tp15282233p15282508.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Query About Request Context
FYI, currently we have some a JIRA[1] for tracing this issue. https://issues.apache.org/jira/browse/CXF-1410 Willem. SantoshAkhilesh wrote: Hi, So far I had an idea that request context is put in thread local but I realized it is not. Why the request context is not threadlocal ? If I want to send multiple client requests and each request having different JMS header using same BindingProvider instance then do I need to synchronize the context or not ? I think now it needs to synchronized else it is overwritten by subsequent calls. Can anyone shed a light on this. Regards, Santosh
Re: Query About Request Context
This link [1] may help your to get the whole story.
[1]http://www.nabble.com/Request-ResponseContext-of-JaxWsClientProxy-td10327781.html#a10335673
Willem.
Sky-Tiger wrote:
See this:
public class JaxWsClientProxy extends org.apache.cxf.frontend.ClientProxy
implements
InvocationHandler, BindingProvider {
private static final Logger LOG =
LogUtils.getL7dLogger(JaxWsClientProxy.class);
protected MapString, Object requestContext = new
ConcurrentHashMapString, Object();
protected ThreadLocal MapString, Object responseContext =
new ThreadLocalMapString, Object();
Anybody can tell me why responseContext is threadlocal but requestContext
is not? That means BindingProvider is not thread-safe!
Is it a bug?
Re: Issue with CXF: Marshalling Error: Error writing request body to server
Hi, Did you enable the MTOM feature? Please refer the below link for more information. http://cwiki.apache.org/CXF20DOC/mtom.html Willem. Tor Arne Kvaløy wrote: Hello! I have ran into a serious problem with CXF on the client side. I have tried quite a few things but I am right now quite stuck, and I hope that you guys have any suggestions. The full stacktrace is in this mail. I get the same error both with 2.0.3 and 2.0.4. Can it be an issue with JAXB, I am using jaxb-impl 2.0.5 from the sun-site. The following error is given when I invoke the web service method. SubmitDataService service = new SubmitDataService(); ISubmitData port = service.getSubmitDataPort(); boolean ret = port.submitData(setId, setName, fileName, getData(fileName), list); INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:207) at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:63) at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:84) at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) at $Proxy26.submitData(Unknown Source) at com.pointcarbon.mule.SubmitDataClient.main(SubmitDataClient.java:85) Caused by: javax.xml.bind.MarshalException - with linked exception: [java.io.IOException: Error writing request body to server] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:297) at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:221) at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:70) at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:360) at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:187) ... 10 more Caused by: java.io.IOException: Error writing request body to server at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2261) at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2244) at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:45) at org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:64) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.flushBuffer(UTF8XmlOutput.java:351) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:304) at com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.writeTo(Base64Data.java:263) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:251) at com.sun.xml.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.java:312) at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$PcdataImpl.writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:140) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:214) at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:62) at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:286) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:619) at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:113) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:98) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 14 more Exception in thread Main Thread javax.xml.ws.soap.SOAPFaultException: Marshalling Error: Error writing request body to server at
Re: WebSecurity error when using Simple Frontend / Aegis binding
Hi ,
There are some difference between the simple front end and jaxws front
end to detail with the fault message.
The WebFault annotation will take effect when you are using the jaxws
front end ,
but when you using simple front you need let the exception class
inherit the org.apache.cxf.frontend.FaultInfoException class.
You can find some more information by digging the
RefactionServiceFactoryBean [1] 's initializeFaults() method.
[1]
https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/simple/src/main/java/org/apache/cxf/service/factory/ReflectionServiceFactoryBean.java
Willem.
yulinxp wrote:
Looking at src for FaultOutInterceptor.java, BindingOperationInfo op is null!
This only happens for Simple Frontend/Aegis binding, not for JAX-WS
Frontend/JAXB binding.
Is there a way to let it work? I am using cxf-2.0.3.
public FaultInfo getFaultForClass(BindingOperationInfo op, Class class1) {
for (BindingFaultInfo bfi : op.getFaults()) {
FaultInfo faultInfo = bfi.getFaultInfo();
Class? c =
(Class)faultInfo.getProperty(Class.class.getName());
if (c.isAssignableFrom(class1)) {
return faultInfo;
}
}
return null;
}
---
///tomcat CXF server exception
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.interceptor.FaultOutInterceptor.getFaultForClass(FaultOutInterceptor.java:
128)
at
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutInterceptor.java:61)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultCha
inInitiatorObserver.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:224)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:7
3)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
va:256)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
What's working for JAX-WS Frontend / JAXB binding does not work for Simple
Frontend / Aegis binding.
Is there anything wrong with my xml? How to fix it?
