Hi,
I think this is a bug of CXF, if the user define the extension in the
service and binding,
we should use the service's value.
Willem
liucong wrote:
Hi all,
In the
SOAP/JMS(http://www.w3.org/TR/2008/WD-soapjms-20081121/#wsdl-11-properties).
If a property is specified at multiple
Hi
I'm not sure yet - it appears JSONProvider may need to be updated to handle
unwrapped cases.
Does anyone know, is it already possible to do somehow in CXF ?
Perhaps one workaround is to register a RequestFilter which will replace an
InputStream on the inbound message with another stream
In fact, I can probably update JSON provider to do it. If it is set to
operate in 'unwrapped' mode then it will append a class name to the stream,
will do it shortly
cheers, Sergey
Sergey Beryozkin wrote:
Hi
I'm not sure yet - it appears JSONProvider may need to be updated to
handle
Hello CXF Devs,
Does CXF have the support for processing nonce at *server* side?
As I understand from some posts CXF creates the nonce automatically when
password digest is used at client side.
If it does not have support yet at server side so does that mean we cannot
use password digest at
Liu,
I just want to say this is very nice work. Thanks for tackling this. It
almost makes me want to go through the rest of the wsdl extension schemas and
make them not subclass the old TExensibilityElementImpl thing. Would
simplify that stuff quite a bit.
Again, nice job.
Dan
On
It's supported in so far as it'll get processed correctly to create the
nonce+created+password digest. But nonce-caching for replay detection
isn't supported as of yet...there's a jira open in WSS4J for it.
Feel free to submit a patch :-)
https://issues.apache.org/jira/browse/WSS-187
Colm.
A test case (attached to a JIRA) would be good if you cannot figure this out.
However, here is a pointer:
When CXF looks in the WSDL to determine the transport factory, it looks at the
FIRST extensor on the port that has a namespace that matches a transport
factory. In your first example, it
Thank you, Dan.
I just found the problem as you said.
I can make the JMSTransportFactory implement WSDLEndpointFactory
interface. And then the SOAPAddress can be used to create
createEndpointInfo. Then the problem will be solved. I'm trying to do this.
liu
Daniel Kulp wrote:
A test case
Sergey,
On Thu July 2 2009 12:59:10 pm Sergey Beryozkin wrote:
I have problems with the JAXB schema generation.
Consider this bean :
@XmlRootElement(name=thebook, namespace=http://books;)
public class Book {
private int id;
public Book() { }
public int getId() { return id; }
Hi Dan
thanks... I'm looking now at JAXBDatabinding's JAXBBeanInfo which looks like exactly what I need - I'm thinking of moving
JAXBBeanInfo and JAXBContextProxy into common/utils/jaxb as at the moment it's not quite feasible to reuse JAXBDataBinding as is
from JAX-RS due to different models.
Hi Dan,
Thank you for your good advice. I think keeping the soap stuff in the
soap binding is a very good idea.
https://issues.apache.org/jira/browse/CXF-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12727756#action_12727756
On Sat July 4 2009 4:31:32 pm Krzysztof Wilkos wrote:
2009/7/3 Krzysztof Wilkos kayn...@gmail.com:
Finally I've got working client. Sun's pdf it's not enought so I ended
with sniffing .Net communication. Tomorrow I'll clean up some code and
submit patch.
Your comment actually got me
12 matches
Mail list logo