Re: Properties Overriding in WSDL usage
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 levels, the most specific setting
will take precedence (port first, then service, then binding).
But I invetigate the code of CXF. I find someting int
org.apache.cxf.service.model.EndpointInfo.getTraversedExtensor(T
defaultValue, ClassT type):
@Override
public T T getTraversedExtensor(T defaultValue, ClassT type) {
T value = getExtensor(type);
if (value == null) {
if (value == null binding != null) {
value = binding.getExtensor(type);
}
if (service != null value == null) {
value = service.getExtensor(type);
}
if (value == null) {
value = defaultValue;
}
}
return value;
}
The code shou that:port first, then binding, then service.
Now. Which is right?
thanks.
Re: Supprot for wrapped/unwrapped styles in Mapped convention for JSON
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 which will present
{name:abc}
as
{employee:{name:abc}}
for small streams (JSON ones are probably all quite small) this should work
quite well. what do you think ?
cheers, Sergey
Chaitanya-10 wrote:
Hi,
I have a JAX-RS method which takes an Employee object as a param. Employee
class is given below.
@XmlRootElement
public class Employee {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
Unmarshalling of the JSON
{employee:{name:abc}}
works fine and gives an Employee object, but if the JSON input is
{name:abc}
unmarshalling fails.
Does CXF support both wrapped and unwrapped styles in Mapped convention
for JSON?
If yes what should be done to make the second case work?
Thank you
Chaithanya.
--
View this message in context:
http://www.nabble.com/Supprot-for-wrapped-unwrapped-styles-in-Mapped-convention-for-JSON-tp24319534p24353159.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Supprot for wrapped/unwrapped styles in Mapped convention for JSON
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 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 which will
present
{name:abc}
as
{employee:{name:abc}}
for small streams (JSON ones are probably all quite small) this should
work quite well. what do you think ?
cheers, Sergey
Chaitanya-10 wrote:
Hi,
I have a JAX-RS method which takes an Employee object as a param.
Employee class is given below.
@XmlRootElement
public class Employee {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
Unmarshalling of the JSON
{employee:{name:abc}}
works fine and gives an Employee object, but if the JSON input is
{name:abc}
unmarshalling fails.
Does CXF support both wrapped and unwrapped styles in Mapped convention
for JSON?
If yes what should be done to make the second case work?
Thank you
Chaithanya.
--
View this message in context:
http://www.nabble.com/Supprot-for-wrapped-unwrapped-styles-in-Mapped-convention-for-JSON-tp24319534p24353228.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Nonce at Server Side
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 server side as combination of timestamp, *nonce* and password text are used to calculate the password digest. May be I read some old post or I am wrong. Kindly correct me. Thanks in advance. Best Regards, Rahul
Re: How to add wsdl extension for SOAP/JMS.
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 Fri July 3 2009 9:10:04 am liucong wrote:
Hi,
I am writing a plugin for xjc.
First I just modify the cxf-xjc-ts and cxf-xjc-ts-test, and make it
work with the -Xwsdlextension, not -Xts. The pom file is also changed.
And it works rightly.
Then I copy the modified projects into cxf-xjc-wsdlextension and
cxf-xjc-wsdlextension-test, and make the cxf-xjc-ts the same with the
subversion.
It failed. The exception is:
[INFO]
[INFO] Building Apache CXF XJC WSDL Extension Plugin Tests
[INFO]task-segment: [install]
[INFO]
[INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
[INFO] [jaxb2:xjc {execution: default}]
[INFO] Generating source...
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] unrecognized parameter -Xwsdlextension
What's wrong? Do I need to do more configuration for ths xjc plugin?
thanks!
Daniel Kulp wrote:
Liu,
I think for stuff that are simple (basically, complexTypes with
simpleContent and simpleType object), you cannot extend
TExtensibilityElementImpl. Instead, you would need to make it implement
ExtensibilityElement interface and add the QName and required fields and
such.
Dan
On Wed July 1 2009 12:18:15 pm liucong wrote:
Hi,
I do a simple experiment about the design sugguest by Dan.
First, I use jaxb, not xjc. I think they have the principle.
The schema like this[1]:
xs:element name=deliveryMode type=soapjms:deliveryModeType /
xs:complexType name=deliveryModeType
xs:simpleContent
xs:extension base=xs:string
/xs:extension
/xs:simpleContent
/xs:complexType
The generated class for DeliveryModeType like this[2]:
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = deliveryModeType, propOrder = {
value
})
public class DeliveryModeType{
@XmlValue
protected String value;
/**
* Gets the value of the value property.
*
* @return
* possible object is
* {...@link String }
*
*/
public String getValue() {
return value;
}
/**
* Sets the value of the value property.
*
* @param value
* allowed object is
* {...@link String }
*
*/
public void setValue(String value) {
this.value = value;
}
public boolean isSetValue() {
return (this.value!= null);
}
}
The DeliveryModeType doesn't extend TExtensibilityElementImpl. So I just
modify the class and make it look like this[3]:
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = deliveryModeType, propOrder = {
value
})
public class DeliveryModeType extends TExtensibilityElementImpl{
@XmlValue
protected String value;
/**
* Gets the value of the value property.
*
* @return
* possible object is
* {...@link String }
*
*/
public String getValue() {
return value;
}
/**
* Sets the value of the value property.
*
* @param value
* allowed object is
* {...@link String }
*
*/
public void setValue(String value) {
this.value = value;
}
public boolean isSetValue() {
return (this.value!= null);
}
}
Then when I publish a service, I get an exception[4]
Creating Service {http://cxf.apache.org/jms_greeter}JMSGreeterService
from WSDL: file:./wsdl/jms_greeter.wsdl
Exception in thread main javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException: Failed to
create service.
at
org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:275) at
org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:209) at
org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderI
mpl .java:84) at javax.xml.ws.Endpoint.publish(Endpoint.java:47)
at demo.jms_greeter.server.Server.init(Server.java:30)
at demo.jms_greeter.server.Server.main(Server.java:34)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
Failed to create service.
at
org.apache.cxf.wsdl11.WSDLServiceFactory.init(WSDLServiceFactory.java:
93) at
RE: Nonce at Server Side
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. -Original Message- From: rahul.soa [mailto:rahul@googlemail.com] Sent: 06 July 2009 11:56 To: dev@cxf.apache.org Cc: Jarek Gawor Subject: Nonce at Server Side 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 server side as combination of timestamp, *nonce* and password text are used to calculate the password digest. May be I read some old post or I am wrong. Kindly correct me. Thanks in advance. Best Regards, Rahul
Re: An Exception occurs when use wsdl extension in the port
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 would be soap and thus would match the soap transport. In the second, it would be soapjms and thus probably matches the JMS transport and not the soap transport. The jms transport probably doesn't look for soap:address. Not sure on the best course of action to solve this. :-( Possibly the soap binding could reset the address on the transport or something. Would be good to check if this is the case before diving in too deep. Dan On Sat July 4 2009 7:51:40 am liucong wrote: Hi all, When I implement the WSDL usage for SOAP/JMS, I encountered an exception. I create an service and invoke it using wsdl-first. If the wsdl file looks like this[1] : wsdl:definitions wsdl:service name=JMSGreeterService wsdl:port binding=tns:JMSGreeterPortBinding name=GreeterPort soap:address location=jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiC onnectionFactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp ;targetService=greeterService / soapjms:timeToLive1000/soapjms:timeToLive /wsdl:port /wsdl:service /wsdl:definitions This service works well. But if the wsdl file looks like this[2] : wsdl:definitions wsdl:service name=JMSGreeterService wsdl:port binding=tns:JMSGreeterPortBinding name=GreeterPort soapjms:timeToLive1000/soapjms:timeToLive soap:address location=jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiC onnectionFactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp ;targetService=greeterService / /wsdl:port /wsdl:service /wsdl:definitions The service is created correctly, but there is an error happen when I invoke this service. By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo endpointInfo, EndpointReferenceType target)'s target parameter is null. It should be jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFacto ry=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiConnection FactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp;targetSe rvice=greeterService. I think there are someting wrong with port parsing in wsdl. Any ideas? best regards liu -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: An Exception occurs when use wsdl extension in the port
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 (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 would be soap and thus would match the soap transport. In the second, it would be soapjms and thus probably matches the JMS transport and not the soap transport. The jms transport probably doesn't look for soap:address. Not sure on the best course of action to solve this. :-( Possibly the soap binding could reset the address on the transport or something. Would be good to check if this is the case before diving in too deep. Dan On Sat July 4 2009 7:51:40 am liucong wrote: Hi all, When I implement the WSDL usage for SOAP/JMS, I encountered an exception. I create an service and invoke it using wsdl-first. If the wsdl file looks like this[1] : wsdl:definitions wsdl:service name=JMSGreeterService wsdl:port binding=tns:JMSGreeterPortBinding name=GreeterPort soap:address location=jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiC onnectionFactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp ;targetService=greeterService / soapjms:timeToLive1000/soapjms:timeToLive /wsdl:port /wsdl:service /wsdl:definitions This service works well. But if the wsdl file looks like this[2] : wsdl:definitions wsdl:service name=JMSGreeterService wsdl:port binding=tns:JMSGreeterPortBinding name=GreeterPort soapjms:timeToLive1000/soapjms:timeToLive soap:address location=jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiC onnectionFactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp ;targetService=greeterService / /wsdl:port /wsdl:service /wsdl:definitions The service is created correctly, but there is an error happen when I invoke this service. By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo endpointInfo, EndpointReferenceType target)'s target parameter is null. It should be jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFacto ry=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiConnection FactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp;targetSe rvice=greeterService. I think there are someting wrong with port parsing in wsdl. Any ideas? best regards liu
Re: Schema generation issues
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; }
public void setId(int ident) { id = ident; }
}
I think you should just add an
@XmlType(name = book, namespace=http://books;)
Attribute to it as well.The XmlRootElement defines a root element, but
doesn't do anything to specify how the type is mapped in.The XmlType
annotation does that.
Dan
JAXBContext generates these 2 schemas :
!-- Schema 1 --
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; version=1.0
targetNamespace=http://books; xs:import schemaLocation=schema2.xsd /
xs:element name=thebook type=book /
/xs:schema
!-- Schema 2 --
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; version=1.0
xs:complexType name=book
xs:sequence
xs:element name=id type=xs:int /
/xs:sequence
/xs:complexType
/xs:schema
The first problem I guess is to check if import in the first schema has
no 'namespace' attribute in which case I can have 'book' complex type
injected directly into the first schema. with the whole import being
removed. It can get quiote hairy if 'book' type improts some other types,
but it can be handled.
What I'm sure about is how to figure out that when we have say a method
public Resource() {
public Book getBook() {}
}
then how to ensure that Book is represented by {http://books}thebook
qualified name in the generated doc such as wadl...
it's not obvious to me how a link between Book and 'thebook' element can be
established given that this info (in XmlRootElement at the moment) may come
from various sources
thanks, Sergey
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: Schema generation issues
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. I'll be revisiting it once/if we do some WSDL2 generation
cheers, Sergey
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; }
public void setId(int ident) { id = ident; }
}
I think you should just add an
@XmlType(name = book, namespace=http://books;)
Attribute to it as well.The XmlRootElement defines a root element, but
doesn't do anything to specify how the type is mapped in.The XmlType
annotation does that.
Dan
JAXBContext generates these 2 schemas :
!-- Schema 1 --
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; version=1.0
targetNamespace=http://books; xs:import schemaLocation=schema2.xsd /
xs:element name=thebook type=book /
/xs:schema
!-- Schema 2 --
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; version=1.0
xs:complexType name=book
xs:sequence
xs:element name=id type=xs:int /
/xs:sequence
/xs:complexType
/xs:schema
The first problem I guess is to check if import in the first schema has
no 'namespace' attribute in which case I can have 'book' complex type
injected directly into the first schema. with the whole import being
removed. It can get quiote hairy if 'book' type improts some other types,
but it can be handled.
What I'm sure about is how to figure out that when we have say a method
public Resource() {
public Book getBook() {}
}
then how to ensure that Book is represented by {http://books}thebook
qualified name in the generated doc such as wadl...
it's not obvious to me how a link between Book and 'thebook' element can be
established given that this info (in XmlRootElement at the moment) may come
from various sources
thanks, Sergey
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: An Exception occurs when use wsdl extension in the port
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 https://issues.apache.org/jira/browse/CXF-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12727756#action_12727756 liu Daniel Kulp wrote: 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 would be soap and thus would match the soap transport. In the second, it would be soapjms and thus probably matches the JMS transport and not the soap transport. The jms transport probably doesn't look for soap:address. Not sure on the best course of action to solve this. :-( Possibly the soap binding could reset the address on the transport or something. Would be good to check if this is the case before diving in too deep. Dan On Sat July 4 2009 7:51:40 am liucong wrote: Hi all, When I implement the WSDL usage for SOAP/JMS, I encountered an exception. I create an service and invoke it using wsdl-first. If the wsdl file looks like this[1] : wsdl:definitions wsdl:service name=JMSGreeterService wsdl:port binding=tns:JMSGreeterPortBinding name=GreeterPort soap:address location=jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiC onnectionFactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp ;targetService=greeterService / soapjms:timeToLive1000/soapjms:timeToLive /wsdl:port /wsdl:service /wsdl:definitions This service works well. But if the wsdl file looks like this[2] : wsdl:definitions wsdl:service name=JMSGreeterService wsdl:port binding=tns:JMSGreeterPortBinding name=GreeterPort soapjms:timeToLive1000/soapjms:timeToLive soap:address location=jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialCon textFactory=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiC onnectionFactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp ;targetService=greeterService / /wsdl:port /wsdl:service /wsdl:definitions The service is created correctly, but there is an error happen when I invoke this service. By debugging, I find that JMSTransportFactory.getConduit(EndpointInfo endpointInfo, EndpointReferenceType target)'s target parameter is null. It should be jms:jndi:dynamicQueues/test.cxf.jmstransport.queue?jndiInitialContextFacto ry=org.apache.activemq.jndi.ActiveMQInitialContextFactoryamp;jndiConnection FactoryName=ConnectionFactoryamp;jndiURL=tcp://localhost:61616amp;targetSe rvice=greeterService. I think there are someting wrong with port parsing in wsdl. Any ideas? best regards liu
Re: SOAP/TCP project status...
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 looking at the pdf. You're right. Definitely some stuff missing there. https://issues.apache.org/jira/browse/CXF-2257 I'm submiting a patch that adds soap over tcp client support. It still needs more error handling end more tests but seems to work. I've tested this with .Net service which is in SoapTcp.zip package. There is also .Net client which I used as a reference as Sun's pdf was not enough. Wireshark can't sniff over looback interface on Windows so I used CommView trial, than save log as .cap and decode in wireshark. The patch is definitely a good start, but definitely needs some work before we get it integrated into the builds. Apart from the legal issue you mentioned off list, there's a bunch of formatting things, header things, maven poms, etc... that we need to tackle. The XPP dep also is an issue. You probably should just be able to call our StaxUtils.createXmlStreamReader to get a standard StAX stream reader to accomplish that. Once we get that cleaned up a bit, I'd definitely like to get it into trunk where it will be easier to collaborate on it and review things a bit better. With the framing stuff in place, we should be able to start extending it for the more advanced things (like the FastInfoSet optimizations). -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
