Re: [VOTE] Alessio Soldano for committer
+1 Freeman Daniel Kulp wrote: Alessio has been one of the primary driving forces behind getting CXF to be a certified JAX-WS provider for JBoss. As part of that work, he has identified several bugs/issues in CXF and has provided patches for many of them. He has also been helping in the communities, especially related to supporting people trying to use CXF with JBoss. In all, he has made significant contributions toward making CXF a better products. Thus, I think he's ready to become a committer. I'll hold the vote open for at least 72 hours. Here is my +1. -- Freeman Fang Open Source SOA: http://fusesource.com
Re: Soap message encoding
Dear Dan, 1)Do you mean that if client request has the Encoding information in the specified attribute then server side does not have to explicitly perform any additional operation to handle this? 2) there is an open defect on CXF about encoding here http://www.mulesource.org/jira/browse/MULE-4011 Will this affect the said functionality? Kindly let me know your opinion on the above mentioned aspects. regards anoopPrasad dkulp wrote: I THINK if you set the Message.ENCODING attribute on the message (for instance, in the RequestContext) to a string denoting the encoding you want, it should be used. I haven't tested that though. On the server side, it should respond in whatever encoding the client sent it in. Dan On Mon June 8 2009 4:35:51 am Sky-Tiger wrote: Hi all, In most scenarios, soap/xml message is encoding with UTF-8. But if i want to use another encoding ,such as UTF-16, GBK... What i do with CXF? Regards Hubert. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- View this message in context: http://www.nabble.com/Soap-message-encoding-tp23920250p23938261.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [VOTE] Alessio Soldano for committer
+1 cheers, Sergey Daniel Kulp wrote: Alessio has been one of the primary driving forces behind getting CXF to be a certified JAX-WS provider for JBoss. As part of that work, he has identified several bugs/issues in CXF and has provided patches for many of them. He has also been helping in the communities, especially related to supporting people trying to use CXF with JBoss. In all, he has made significant contributions toward making CXF a better products. Thus, I think he's ready to become a committer. I'll hold the vote open for at least 72 hours. Here is my +1. -- Freeman Fang Open Source SOA: http://fusesource.com
RE: [VOTE] Alessio Soldano for committer
+1 -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: 08 June 2009 20:32 To: dev@cxf.apache.org Subject: [VOTE] Alessio Soldano for committer Alessio has been one of the primary driving forces behind getting CXF to be a certified JAX-WS provider for JBoss. As part of that work, he has identified several bugs/issues in CXF and has provided patches for many of them. He has also been helping in the communities, especially related to supporting people trying to use CXF with JBoss. In all, he has made significant contributions toward making CXF a better products. Thus, I think he's ready to become a committer. I'll hold the vote open for at least 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: [VOTE] Alessio Soldano for committer
+1 David 2009/6/8 Daniel Kulp dk...@apache.org: Alessio has been one of the primary driving forces behind getting CXF to be a certified JAX-WS provider for JBoss. As part of that work, he has identified several bugs/issues in CXF and has provided patches for many of them. He has also been helping in the communities, especially related to supporting people trying to use CXF with JBoss. In all, he has made significant contributions toward making CXF a better products. Thus, I think he's ready to become a committer. I'll hold the vote open for at least 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: [VOTE] Alessio Soldano for committer
+1, -- Ulhas Daniel Kulp wrote: Alessio has been one of the primary driving forces behind getting CXF to be a certified JAX-WS provider for JBoss. As part of that work, he has identified several bugs/issues in CXF and has provided patches for many of them. He has also been helping in the communities, especially related to supporting people trying to use CXF with JBoss. In all, he has made significant contributions toward making CXF a better products. Thus, I think he's ready to become a committer. I'll hold the vote open for at least 72 hours. Here is my +1.
Invalid soap messagein web service request
Hi All, I am Naresh. Iam usig cxf-2.1.2 version. I was able to execute my web service successfully. But sometimes, when web service client tries to send message to web service server, the soap message was in the following form ?xml version=?x1m.l0 v e?rsion=1.0 ?S:EnvelopeS :xEmnlvnesl:oSp=e http://sc hxemmlanss.:xSm=lsoap.orhgt/tspo:a/p//secnhveemlaosp.ex/mls oap.org/sodyS:Body The soap message was repeated itself. And this was not reproducible everytime. So could any one please help me to resolve this issue. Why the SOAP message is rendered like that and what is fix for it. Any help is much appreciated. Thank you, Naresh.
Re: Invalid soap messagein web service request
I BELIEVE this is due to using the Sun's StAX parser. Two options to fix this: 1) Make sure you pickup woodstox instead of the sun parser. 2) Upgrade to CXF 2.2.2 which works around this issue. Dan On Tue June 9 2009 8:19:06 am Naresh Tallapelli wrote: Hi All, I am Naresh. Iam usig cxf-2.1.2 version. I was able to execute my web service successfully. But sometimes, when web service client tries to send message to web service server, the soap message was in the following form ?xml version=?x1m.l0 v e?rsion=1.0 ?S:EnvelopeS :xEmnlvnesl:oSp=e http://sc hxemmlanss.:xSm=lsoap.orhgt/tspo:a/p//secnhveemlaosp.ex/mls oap.org/sodyS:Body The soap message was repeated itself. And this was not reproducible everytime. So could any one please help me to resolve this issue. Why the SOAP message is rendered like that and what is fix for it. Any help is much appreciated. Thank you, Naresh. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: How to implement the SOAP Fault for JMS Transport?
Ideally, to me, this type of fault mapping needs to be in the SOAP binding, not the JMS transport.The JMS transport needs to be somewhat independent of soap so that it's usable for things like XML over JMS and possibly even some resty things. Basically, the SOAP binding should examine it's transportId and if it's the SOAP/JMS spec defined ID, it should add some extra interceptors to handle the mapping of the soap specific things into the non-soap specific things in the transport. For example: all the funky JMS headers that the SOAP/JMS spec requires should be done from an interceptor provided by the SOAP binding (put them in the Message.PROTOCOL_HEADERS map) that the JMS transport would just copy across. That said, I really haven't read the SOAP/JMS spec in very much detail so I'm not sure if it's completely possible. :-) Dan On Mon June 8 2009 10:54:18 pm liucong wrote: Hi, Willem Jiang Writes: Hi, I think you mean how to throw the fault from the JMS transport. Basically , if you throw the fault from a CXF interceptor, CXF's interceptors chain will take care of it and build the fault message and throw it out. If you want to check the Content type , you could write an interceptor and load it with your soap jms transport. How to load an interceptor with my soap jms transport? Is there any material for help? Thank you. But I think you could take the soap binding (SoapBindingFactory) as an example, and put this kind of checking as a work of soap jms binding. Just my 2 cents, Willem liucong wrote: Hi all, When I implement the SOAP Over JMS Specification, I don’t know how to implement SOAP fault for it. I use the org.apache.cxf.interceptor.Fault to record the Fault information. For example, I create a Fault instance for SOAP fault subcode contentTypeMismatch (http://www.w3.org/TR/2008/WD-soapjms-20080723/#binding-faults). If I check the fault the cxf-rt-transports-jms module, I don’t know how to deal with the fault which is checked out. If I added an Interceptor for JMS transport, I can use the interceptor to deal with the fault. Is It right? If it is Ok, how is the interceptor added to the interceptors according to whether the jms transport is used or not? Are there any materials for interceptors, phases, and phase order? Thank you very much! Best regards, Liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Integrating JAX-RS runtime into DOSGi
Sergey Beryozkin wrote: This means that AbstractPojoConfigurationTypeHandler.createClientProxyFactoryBean() won't be able to return a JAXRSClientFactoryBean. What do you think about this idea. The factory which returns handlers can check first if a given service intents include HTTP but no SOAP and a frontend.jaxrs property is set, and if yes then it returns JaxRSPojoConfigurationTypeHandler which will do what PojoConfigurationTypeHandler but use JAXRS factories instead. The common code, if any, can be refactored away into OSGIUtils. I agree it would be great if a common interface was there but may be we will be able to get to it at some later stage and collapse handlers into a single one... Thanks, Sergey I can't seem to find JaxRSPojoConfigurationTypeHandler anywhere in the source. I thought this was something that had been written and committed already. Should I be looking in a branch for this? Thanks, Josh -- Josh Holtzman Educational Technology Services, UC Berkeley jholtz...@berkeley.edu 510.529.9225
