DOSGI - problem with jax-ws
Hi all, I have a problem getting the greeter sample to work with jax-ws frontend using the current cxf-dosgi-1.1-snapshot. The resulting wsdl is missing all type and operations definitions. I simply added he following properties to my activator: props.put(org.apache.cxf.ws.frontend, jaxws); props.put(org.apache.cxf.ws.databinding, jaxb); This results in a greeter server whos generated wsdl has no type definitions or operations. I tried adding the @WebService annotation to the impl class which did not help. Any hints? Regards Björn
Re: DOSGI - problem with jax-ws
Hi I think you may need to import javax.jws.* into your service bundle. Can you give it a try please ? cheers, Sergey - Original Message - From: Björn Schütte bjo...@schuette.se To: dev@cxf.apache.org Sent: Thursday, July 16, 2009 10:39 AM Subject: DOSGI - problem with jax-ws Hi all, I have a problem getting the greeter sample to work with jax-ws frontend using the current cxf-dosgi-1.1-snapshot. The resulting wsdl is missing all type and operations definitions. I simply added he following properties to my activator: props.put(org.apache.cxf.ws.frontend, jaxws); props.put(org.apache.cxf.ws.databinding, jaxb); This results in a greeter server whos generated wsdl has no type definitions or operations. I tried adding the @WebService annotation to the impl class which did not help. Any hints? Regards Björn
Re: Support for Json arrays
I have just completed an initial work for supporting reading/writing explicit
collections or arrays.
Unfortunately, as far as JSON is concerned, only writing is supported. There
appears to be some issue at the Jettison level and we'll be trying to
identify it so that a Jettison JIRA can be opened. I'll keep you updated
Cheers, Sergey
Chaitanya-10 wrote:
Hi,
I have a JAX-RS method which takes an array of Employee objects 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}, {name : xyz} ] }
fails.
Does CXF support unmarshalling/marshalling of arrays?
I could not find a bug on this in the issue tracker and I am not sure if
this is a bug in CXF or Jettison. Please let me know if this issue is
already fixed in the latest release(Iam using CXF 2.2 sanpshot currently).
Thank you
Chaithanya.
--
View this message in context:
http://www.nabble.com/Support-for-Json-arrays-tp24409855p24517228.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: DOSGI - problem with jax-ws
Hi Sergey, I've tried it, but same result :-( greetings, Björn Sergey Beryozkin-2 wrote: Hi I think you may need to import javax.jws.* into your service bundle. Can you give it a try please ? cheers, Sergey - Original Message - From: Björn Schütte bjo...@schuette.se To: dev@cxf.apache.org Sent: Thursday, July 16, 2009 10:39 AM Subject: DOSGI - problem with jax-ws Hi all, I have a problem getting the greeter sample to work with jax-ws frontend using the current cxf-dosgi-1.1-snapshot. The resulting wsdl is missing all type and operations definitions. I simply added he following properties to my activator: props.put(org.apache.cxf.ws.frontend, jaxws); props.put(org.apache.cxf.ws.databinding, jaxb); This results in a greeter server whos generated wsdl has no type definitions or operations. I tried adding the @WebService annotation to the impl class which did not help. Any hints? Regards Björn -- View this message in context: http://www.nabble.com/DOSGI---problem-with-jax-ws-tp24514255p24517401.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: jaxp-api exclusion from parent/pom.xml
Well, ideally all of the stuff in jaxp-api are part of the JDK or pulled from stax-api.It looks like there are two classes (StAXResult and StAXSource) that aren't in either unless running on IBM Java 6. That kind of sucks. I guess that exclusion should be removed. Dan On Wed July 15 2009 5:58:05 pm Peter Jones wrote: Hi there, cxf includes the jaxp-ri as a dependency when needed in a couple of places (only when running with the ibm jdk), but I notice that in the parent/pom.xml, jaxp-api is specifically excluded: dependency groupIdcom.sun.xml.parsers/groupId artifactIdjaxp-ri/artifactId version1.4.2/version exclusions exclusion groupIdjavax.xml.parsers/groupId artifactIdjaxp-api/artifactId /exclusion /exclusions /dependency Is there a good reason to exclude it? I'm seeing some test failures in common/common when using the ibm jdk (StaxUtilsTest, W3CDOMStreamReaderTest, and XMLUtilsTest). They hit a NoClassDefFoundError for javax.xml.transform.stax.StAXResult. If I don't exclude the jaxp-api, the tests run fine, and thus why I am wondering if there is a good reason... Regards, Peter Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
RE: jaxp-api exclusion from parent/pom.xml
Hi Dan, Yeah that does kind of suck. I'll remove the exclusion from the dependency. Regards, Peter Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Thu 7/16/2009 3:04 PM To: dev@cxf.apache.org Cc: Peter Jones Subject: Re: jaxp-api exclusion from parent/pom.xml Well, ideally all of the stuff in jaxp-api are part of the JDK or pulled from stax-api.It looks like there are two classes (StAXResult and StAXSource) that aren't in either unless running on IBM Java 6. That kind of sucks. I guess that exclusion should be removed. Dan On Wed July 15 2009 5:58:05 pm Peter Jones wrote: Hi there, cxf includes the jaxp-ri as a dependency when needed in a couple of places (only when running with the ibm jdk), but I notice that in the parent/pom.xml, jaxp-api is specifically excluded: dependency groupIdcom.sun.xml.parsers/groupId artifactIdjaxp-ri/artifactId version1.4.2/version exclusions exclusion groupIdjavax.xml.parsers/groupId artifactIdjaxp-api/artifactId /exclusion /exclusions /dependency Is there a good reason to exclude it? I'm seeing some test failures in common/common when using the ibm jdk (StaxUtilsTest, W3CDOMStreamReaderTest, and XMLUtilsTest). They hit a NoClassDefFoundError for javax.xml.transform.stax.StAXResult. If I don't exclude the jaxp-api, the tests run fine, and thus why I am wondering if there is a good reason... Regards, Peter Peter Jones Progress Software 570 Newfoundland Drive St. John's, NL, Canada A1A 5B1 Tel: +1 (709) 738-3725 ext 321 Internal wiki: http://wiki.progress.com/display/PRODENG/Home -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
