CXF 2.0 client and Websphere 6.1 with WS feature pack
Hi All, I need some help with Websphere 6.1 and CXF. I wrote a Web Services client (using basic authentication) with CXF. I followed these instructions nto setup Websphere: http://cwiki.apache.org/confluence/display/CXF20DOC/AppServerGuide#AppServerGuide-Websphere But I have the same issue than this guy: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14017733 Basically WAS 6.1 checks the annotation and complains about org.apache.cxf.js.rhino.DOMPayloadProvider not implemented in the right way. Is this guy from IBM right? Our generated client uses only standard Web services annotations and we have to use a HTTPConduit. Any ideas how to disable this check or to make it works? Any help will be much appreciated. Have a nice day. JR
Regarding elementFormDefault
Hi, I am using CXF 2.0.2. I am facing the same issues discussed in the following thread, http://www.nabble.com/Created:-(CXF-1226)-Missing-input-output-param-namespace-in-SOAP-td13870857.html Using java first approach, with Service class or Interface, generated WSDL has, *elementFormDefault*=unqualified Finally wsdl2java generates package-info.java having XmlSchema element having NO elementFormDefault attribute (considered as unqualified as default option (I understand TCK requires it to be unqualified)) Is hardcoding in package-info.java on server and client is the only option? or can I generate package-info.java with this elementFormDefault attribute using some switches in wsdltojava or JAXB/JAXWS changes? Also, Please let me know, is there any patch available on CXF 2.0.2 which can help to solve this problem, or any solution to CXF-1226 [1] which solves this problem. Do let me know if I made wrong assumptions in approach. [1]. https://issues.apache.org/jira/browse/CXF-1226 With Regards, Mayank
RE: Issues with JSON based Service and Jettison
Hi Benson, Thank you for the insights. I feel quite honestly like I'm swimming through Jello a bit, as I cannot find an end to end JSON/CXF/Jettison example, so I'm gleaming info from past mails on the mailing list and some general common sense - I certainly believe it could be my error in so much that I have not configured something correctly - or my way of thinking about the problem incorrectly. I'm having issues even trying to test simple cases. In any event, I'll keep plugging. -Tony -Original Message- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: Thursday, January 17, 2008 9:12 AM To: cxf-user@incubator.apache.org Cc: [EMAIL PROTECTED] Subject: RE: Issues with JSON based Service and Jettison On Thu, 2008-01-17 at 09:06 -0500, Vespa, Anthony J wrote: Hi Jervis, I was able to get past that part yesterday - but I seem to be having some more problems with just the general namespace. Anthony, A general caveat. You are combining Aegis with JSON, which is not a heavily tested combination. You are using the 'just like JAXB' annotations on Aegis, instead of the primary Aegis idea, which is mapping XML files. You may have problems, and you'll have to be willing to create isolated test cases and attach them to JIRA entries. If you are just experimenting, you might want to use .aegis.xml files (or even consider JAXB), rather than plough this furrow. --benson
Re: Maven dependency problem upgrading from CXF 2.0.2 to 2.0.3
Geln, You aren't, by any chance, on a Mac? Are you? Dan On Thursday 17 January 2008, Glen Mazza wrote: Hello, I'm having difficulty upgrading from CXF 2.0.2 to CXF 2.0.3 using Mavenized builds. With CXF 2.0.3 (not 2.0.2), Maven keeps trying to download nonexistent versions of jars (in particular, Version 1.0 of cxf-api and cxf-rt-core, neither of which have 1.0 versions anywhere) and fails because it cannot find them. As you can see below, running mvn clean install with the debug (-X) option seems to show that cxf-rt-transports-http-jetty is the culprit: it is resolving its dependencies to the invalid 1.0 versions while cxf-rt-frontend-jaxws is requesting the normal, available, 2.0.3 versions. [DEBUG] org.apache.cxf:cxf-rt-transports-http-jetty:jar:2.0.3-incubator:compil e (selected for compile) --[DEBUG] org.apache.cxf:cxf-api:jar:1.0:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-transports-http:jar:1.0:compile (applying version: 2.0.3-incubator) [DEBUG] org.apache.cxf:cxf-rt-transports-http:jar:2.0.3-incubator:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected for compile) [DEBUG] org.mortbay.jetty:jetty:jar:6.1.5:compile (selected for compile) [DEBUG] org.mortbay.jetty:jetty-util:jar:6.1.5:compile (selected for compile) [DEBUG] org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.1-M1:compile (selected for compile) [DEBUG] commons-lang:commons-lang:jar:2.3:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] javax.xml.ws:jaxws-api:jar:2.0:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) --[DEBUG] org.apache.cxf:cxf-rt-core:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) [DEBUG] org.apache.cxf:cxf-rt-bindings-soap:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) [DEBUG] org.apache.cxf:cxf-tools-common:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] velocity:velocity:jar:1.4:compile (selected for compile) [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) I'm still somewhat early in my troubleshooting, I'm going to simplify the pom files next to the bare minimum that reproduces this error. In the meantime, though, has anyone seen this error before? I am hoping that someone would know what might cause this to save me troubleshooting time. Also, when does one need the cxf-rt-transports-http-jetty dependency? Is it a requirement for Jetty use--we are using Jetty so I cannot remove this dependency (which might indirectly fix this problem) if Jetty requires it. I might be able to pull it out of compilation scope, however. Thanks, Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
JMS Topic and CXF
Hi, I was wondering if it is possible to open a JMS topic or queue using CXF. I know from the mailing-list and the doc that it is possible to send messages to a topic and a queue but I could not find anything to answer my question... If the answer is no, has anybody ever tried a lightweight and low latency JMS provider that is not a j2ee server?? Thanks, Benjamin
Re: Maven dependency problem upgrading from CXF 2.0.2 to 2.0.3
Hmm... OK Not sure what to say then although it's probably the same
issue as ServiceMix had on the Mac.
There is a bug in Maven where system properties can overwrite and affect
anything that uses ${project.version} and/or ${pom.version} like we
do. The issue is that some XML parsers or processor (like the one
built into the OSX jvm) has a tendency to set a version system
property which messes that up.Thus, any plugin that does XML
processing at all can cause major issues. Unfortunately, our wsdl2java
plugin does XML processing.
One way to see if that really is the issue it to do:
mvn clean install
then just
mvn install
If the first fails, but the second passes, that's likely the culprit as
the second install will skip processing anything since the first one did
it. For 2.0.4, we're working around it in the codegen plugin by
recording and saving the system properties around the code generation so
when the plugin exits, things are restored. That said, if you have any
other maven plugins that do some xml processing, they could be causing
the same issue.
Suggestion to try:
Run 'mvn -X' and look at the dependency reports. (possibly use the
dependency plugin as well) See if anything that looks like an XML
parser or processor (like xalan or saxon or something) is being pulled
in. If so, see if you can exclude it. That MIGHT work.
Dan
On Thursday 17 January 2008, Glen Mazza wrote:
No, Windows XP Professional, SP2.
dkulp wrote:
Geln,
You aren't, by any chance, on a Mac? Are you?
Dan
On Thursday 17 January 2008, Glen Mazza wrote:
Hello,
I'm having difficulty upgrading from CXF 2.0.2 to CXF 2.0.3 using
Mavenized builds. With CXF 2.0.3 (not 2.0.2), Maven keeps trying
to download nonexistent versions of jars (in particular, Version
1.0 of cxf-api and cxf-rt-core, neither of which have 1.0 versions
anywhere) and fails because it cannot find them. As you can see
below, running mvn clean install with the debug (-X) option seems
to show that cxf-rt-transports-http-jetty is the culprit: it is
resolving its dependencies to the invalid 1.0 versions while
cxf-rt-frontend-jaxws is requesting the normal, available, 2.0.3
versions.
[DEBUG]
org.apache.cxf:cxf-rt-transports-http-jetty:jar:2.0.3-incubator:com
pil e (selected for compile)
--[DEBUG] org.apache.cxf:cxf-api:jar:1.0:compile (selected for
compile) [DEBUG]
org.apache.cxf:cxf-rt-transports-http:jar:1.0:compile (applying
version: 2.0.3-incubator)
[DEBUG]
org.apache.cxf:cxf-rt-transports-http:jar:2.0.3-incubator:compile
(selected for compile)
--[DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile
(selected for compile)
[DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected
for compile)
[DEBUG] org.mortbay.jetty:jetty:jar:6.1.5:compile (selected for
compile) [DEBUG]
org.mortbay.jetty:jetty-util:jar:6.1.5:compile (selected for
compile)
[DEBUG]
org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.1-M1:comp
ile (selected for compile)
[DEBUG] commons-lang:commons-lang:jar:2.3:compile (selected for
compile) [DEBUG]
org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0.3-incubator:compile
(selected for compile)
[DEBUG] javax.xml.ws:jaxws-api:jar:2.0:compile (selected for
compile) --[DEBUG]
org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed -
nearer found: 1.0)
--[DEBUG]
org.apache.cxf:cxf-rt-core:jar:2.0.3-incubator:compile (removed -
nearer found: 1.0)
[DEBUG]
org.apache.cxf:cxf-rt-bindings-soap:jar:2.0.3-incubator:compile
(selected for compile)
[DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile
(removed - nearer found: 1.0)
[DEBUG]
org.apache.cxf:cxf-tools-common:jar:2.0.3-incubator:compile
(selected for compile)
[DEBUG] velocity:velocity:jar:1.4:compile (selected for
compile) [DEBUG] velocity:velocity-dep:jar:1.4:runtime
(selected for runtime)
I'm still somewhat early in my troubleshooting, I'm going to
simplify the pom files next to the bare minimum that reproduces
this error. In the meantime, though, has anyone seen this error
before? I am hoping that someone would know what might cause this
to save me
troubleshooting time.
Also, when does one need the cxf-rt-transports-http-jetty
dependency? Is it a requirement for Jetty use--we are using Jetty
so I cannot remove this dependency (which might indirectly fix this
problem) if Jetty requires it. I might be able to pull it out of
compilation scope, however.
Thanks,
Glen
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
RE: Issues with JSON based Service and Jettison
On Thu, 2008-01-17 at 09:06 -0500, Vespa, Anthony J wrote: Hi Jervis, I was able to get past that part yesterday - but I seem to be having some more problems with just the general namespace. Anthony, A general caveat. You are combining Aegis with JSON, which is not a heavily tested combination. You are using the 'just like JAXB' annotations on Aegis, instead of the primary Aegis idea, which is mapping XML files. You may have problems, and you'll have to be willing to create isolated test cases and attach them to JIRA entries. If you are just experimenting, you might want to use .aegis.xml files (or even consider JAXB), rather than plough this furrow. --benson
RE: Issues with JSON based Service and Jettison
Hi Jervis, I was able to get past that part yesterday - but I seem to be having some more problems with just the general namespace. I can submit the data in but it is being marshalled out incorrectly and exceptionin - I believe I have set up the xml attributes correctly on each of my objecrs, there are akin to: @XmlType(name = wsResponse, namespace = http://json.ws.bos.cbs.com/;, extensibleElements=false) At the top of each of my objects or entity classes. This exception seems to occur after each attempt to loadf data into my objects prior to writing the output. Effectively I am using Eclipselink to access my db, which then populates the objects, and values for those objects get put into a wrapper class, but the exeception now happens outbound and I'm not sure why. I'm taking a look through the source but can't really determine what about my stuff is breaking it. Jan 16, 2008 2:45:34 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: Invalid JSON namespace: http://json.ws.bos.cbs.com/ at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java: 209) at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:74) at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts( AbstractOutDatabindingInterceptor.java:95) at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInter ceptor.java:68) at org.apache.cxf.binding.xml.interceptor.XMLMessageOutInterceptor.handleMe ssage(XMLMessageOutInterceptor.java:71) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:207) at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgoi ngChainInterceptor.java:74) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC hain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiati onObserver.java:78) at org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDes tination.java:79) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(Ser vletController.java:264) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletControl ler.java:123) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFSe rvlet.java:170) at org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFSe rvlet.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(Applica tionFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.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:2 63) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84 4) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: Invalid JSON namespace: http://json.ws.bos.cbs.com/ at org.codehaus.jettison.mapped.MappedNamespaceConvention.getJSONNamespace( MappedNamespaceConvention.java:148) at org.codehaus.jettison.mapped.MappedNamespaceConvention.createKey(MappedN amespaceConvention.java:155) at org.codehaus.jettison.mapped.MappedXMLStreamWriter.writeStartElement(Map pedXMLStreamWriter.java:220) at com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.beginStartTag(X MLStreamWriterOutput.java:70) at com.sun.xml.bind.v2.runtime.output.NamespaceContextImpl$Element.startEle ment(NamespaceContextImpl.java:428) at com.sun.xml.bind.v2.runtime.XMLSerializer.endNamespaceDecls(XMLSerialize r.java:254) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.j ava:612) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementB eanInfoImpl.java:93) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementB eanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBea nInfoImpl.java:244) at
Maven dependency problem upgrading from CXF 2.0.2 to 2.0.3
Hello, I'm having difficulty upgrading from CXF 2.0.2 to CXF 2.0.3 using Mavenized builds. With CXF 2.0.3 (not 2.0.2), Maven keeps trying to download nonexistent versions of jars (in particular, Version 1.0 of cxf-api and cxf-rt-core, neither of which have 1.0 versions anywhere) and fails because it cannot find them. As you can see below, running mvn clean install with the debug (-X) option seems to show that cxf-rt-transports-http-jetty is the culprit: it is resolving its dependencies to the invalid 1.0 versions while cxf-rt-frontend-jaxws is requesting the normal, available, 2.0.3 versions. [DEBUG] org.apache.cxf:cxf-rt-transports-http-jetty:jar:2.0.3-incubator:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-api:jar:1.0:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-transports-http:jar:1.0:compile (applying version: 2.0.3-incubator) [DEBUG] org.apache.cxf:cxf-rt-transports-http:jar:2.0.3-incubator:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected for compile) [DEBUG] org.mortbay.jetty:jetty:jar:6.1.5:compile (selected for compile) [DEBUG] org.mortbay.jetty:jetty-util:jar:6.1.5:compile (selected for compile) [DEBUG] org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.1-M1:compile (selected for compile) [DEBUG] commons-lang:commons-lang:jar:2.3:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] javax.xml.ws:jaxws-api:jar:2.0:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) --[DEBUG] org.apache.cxf:cxf-rt-core:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) [DEBUG] org.apache.cxf:cxf-rt-bindings-soap:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) [DEBUG] org.apache.cxf:cxf-tools-common:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] velocity:velocity:jar:1.4:compile (selected for compile) [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) I'm still somewhat early in my troubleshooting, I'm going to simplify the pom files next to the bare minimum that reproduces this error. In the meantime, though, has anyone seen this error before? I am hoping that someone would know what might cause this to save me troubleshooting time. Also, when does one need the cxf-rt-transports-http-jetty dependency? Is it a requirement for Jetty use--we are using Jetty so I cannot remove this dependency (which might indirectly fix this problem) if Jetty requires it. I might be able to pull it out of compilation scope, however. Thanks, Glen -- View this message in context: http://www.nabble.com/Maven-dependency-problem-upgrading-from-CXF-2.0.2-to-2.0.3-tp14921161p14921161.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Maven dependency problem upgrading from CXF 2.0.2 to 2.0.3
No, Windows XP Professional, SP2. dkulp wrote: Geln, You aren't, by any chance, on a Mac? Are you? Dan On Thursday 17 January 2008, Glen Mazza wrote: Hello, I'm having difficulty upgrading from CXF 2.0.2 to CXF 2.0.3 using Mavenized builds. With CXF 2.0.3 (not 2.0.2), Maven keeps trying to download nonexistent versions of jars (in particular, Version 1.0 of cxf-api and cxf-rt-core, neither of which have 1.0 versions anywhere) and fails because it cannot find them. As you can see below, running mvn clean install with the debug (-X) option seems to show that cxf-rt-transports-http-jetty is the culprit: it is resolving its dependencies to the invalid 1.0 versions while cxf-rt-frontend-jaxws is requesting the normal, available, 2.0.3 versions. [DEBUG] org.apache.cxf:cxf-rt-transports-http-jetty:jar:2.0.3-incubator:compil e (selected for compile) --[DEBUG] org.apache.cxf:cxf-api:jar:1.0:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-transports-http:jar:1.0:compile (applying version: 2.0.3-incubator) [DEBUG] org.apache.cxf:cxf-rt-transports-http:jar:2.0.3-incubator:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-core:jar:1.0:compile (selected for compile) [DEBUG] org.mortbay.jetty:jetty:jar:6.1.5:compile (selected for compile) [DEBUG] org.mortbay.jetty:jetty-util:jar:6.1.5:compile (selected for compile) [DEBUG] org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.1-M1:compile (selected for compile) [DEBUG] commons-lang:commons-lang:jar:2.3:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] javax.xml.ws:jaxws-api:jar:2.0:compile (selected for compile) --[DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) --[DEBUG] org.apache.cxf:cxf-rt-core:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) [DEBUG] org.apache.cxf:cxf-rt-bindings-soap:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] org.apache.cxf:cxf-api:jar:2.0.3-incubator:compile (removed - nearer found: 1.0) [DEBUG] org.apache.cxf:cxf-tools-common:jar:2.0.3-incubator:compile (selected for compile) [DEBUG] velocity:velocity:jar:1.4:compile (selected for compile) [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) I'm still somewhat early in my troubleshooting, I'm going to simplify the pom files next to the bare minimum that reproduces this error. In the meantime, though, has anyone seen this error before? I am hoping that someone would know what might cause this to save me troubleshooting time. Also, when does one need the cxf-rt-transports-http-jetty dependency? Is it a requirement for Jetty use--we are using Jetty so I cannot remove this dependency (which might indirectly fix this problem) if Jetty requires it. I might be able to pull it out of compilation scope, however. Thanks, Glen -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog -- View this message in context: http://www.nabble.com/Maven-dependency-problem-upgrading-from-CXF-2.0.2-to-2.0.3-tp14921161p14921863.html Sent from the cxf-user mailing list archive at Nabble.com.
CXF Servlet setup problem
All the sample use the following to start Spring and loads beans.xml file. context-param param-namecontextConfigLocation/param-name param-valueWEB-INF/beans.xml/param-value /context-param listener listener-class org.springframework.web.context.ContextLoaderListener /listener-class /listener In my existing application, there is a customized springLoader in place. Thus I can't use ContextLoaderListener anymore. Neither can I plug in cxf into customized springLoader. Is there any otherway to load beans.xml? I remember in XFire, we only define servlet-class and servlet-mapping, then it will automatically look for META-INF/xfire/services.xml. Can we do that in CXF? how? web-app servlet servlet-nameXFireServlet/servlet-name display-nameXFire Servlet/display-name servlet-class org.codehaus.xfire.transport.http.XFireConfigurableServlet /servlet-class /servlet servlet-mapping servlet-nameXFireServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping /web-app -- View this message in context: http://www.nabble.com/CXF-Servlet-setup-problem-tp14924060p14924060.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: JMS Topic and CXF
Benjamin Coiffe wrote: I was wondering if it is possible to open a JMS topic or queue using CXF. I know from the mailing-list and the doc that it is possible to send messages to a topic and a queue but I could not find anything to answer my question... http://cwiki.apache.org/CXF20DOC/jms-transport.html has an example (Using a named reply destination) of a jms:address element that uses the dynamicQueues feature of ActiveMQInitialContextFactory to create a queue on the fly. That example is in terms of a WSDL extension but you could use the same kind of thing in the relevant jms:conduit in a bean config file. http://activemq.apache.org/jndi-support.html explains the ActiveMQ side of things. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Polymorphic dispatch, JAXB REST.
I have an rd project on the go and I'm having difficulty getting a rest
service to dispatch correctly.
I have these two classes
@XmlTransient
public class Transaction implements Serializable { ... }
@XmlRootElement(name = transactionType1)
public class TransactionType1 extends Transaction implements Serializable {
.. }
If I try to feed a TransactionType1 instance into this
@HttpMethod(POST)
@ProduceMime(application/xml)
@UriTemplate(/transaction/)
public Response addTransaction(Transaction transaction) { ... }
I see
java.lang.NullPointerException
at
org.apache.cxf.jaxrs.JAXRSUtils.readFromEntityBody(JAXRSUtils.java:224)
at
org.apache.cxf.jaxrs.JAXRSUtils.processParameter(JAXRSUtils.java:199)
However if I change the method signature to accept TransactionType1 it works
fine. What I'm really after, as you probably guessed, is to dispatch
multiple transaction types through the same endpoint.
Thanks in advance - TtF
--
View this message in context:
http://www.nabble.com/Polymorphic-dispatch%2C-JAXB-REST.-tp14928185p14928185.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Servlet setup problem
you can add an init parameter to your servlet, the cxf bus must already be loaded by the spring context already thou init-param param-nameconfig-location/param-name param-valuews.context.xml/param-value /init-param On Jan 17, 2008 4:59 PM, yulinxp [EMAIL PROTECTED] wrote: All the sample use the following to start Spring and loads beans.xml file. context-param param-namecontextConfigLocation/param-name param-valueWEB-INF/beans.xml/param-value /context-param listener listener-class org.springframework.web.context.ContextLoaderListener /listener-class /listener In my existing application, there is a customized springLoader in place. Thus I can't use ContextLoaderListener anymore. Neither can I plug in cxf into customized springLoader. Is there any otherway to load beans.xml? I remember in XFire, we only define servlet-class and servlet-mapping, then it will automatically look for META-INF/xfire/services.xml. Can we do that in CXF? how? web-app servlet servlet-nameXFireServlet/servlet-name display-nameXFire Servlet/display-name servlet-class org.codehaus.xfire.transport.http.XFireConfigurableServlet /servlet-class /servlet servlet-mapping servlet-nameXFireServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping /web-app -- View this message in context: http://www.nabble.com/CXF-Servlet-setup-problem-tp14924060p14924060.html Sent from the cxf-user mailing list archive at Nabble.com.
RE: JMS Topic and CXF
We have samples in the binary kit showing how to use queue and topic with CXF. Regards, Ulhas Bhole -Original Message- From: Ian Roberts [mailto:[EMAIL PROTECTED] Sent: 17 January 2008 17:57 To: cxf-user@incubator.apache.org Subject: Re: JMS Topic and CXF Benjamin Coiffe wrote: I was wondering if it is possible to open a JMS topic or queue using CXF. I know from the mailing-list and the doc that it is possible to send messages to a topic and a queue but I could not find anything to answer my question... http://cwiki.apache.org/CXF20DOC/jms-transport.html has an example (Using a named reply destination) of a jms:address element that uses the dynamicQueues feature of ActiveMQInitialContextFactory to create a queue on the fly. That example is in terms of a WSDL extension but you could use the same kind of thing in the relevant jms:conduit in a bean config file. http://activemq.apache.org/jndi-support.html explains the ActiveMQ side of things. Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Maven dependency problem upgrading from CXF 2.0.2 to 2.0.3
Thanks for the help Dan. I think I'm getting a solution--I just need to
explicitly state the version of cxf-api and cxf-runtime-core that I need in
the DependencyManagement/ section, rather than rely on Maven's default
dependency resolution. Another option that seems to work is using
dependency exclusion filters; i.e. placing exclusions on the two cxf
artifacts wrongfully trying to bring in nonexistent 1.0 jars. Because other
cxf artifacts are correctly bringing in 2.0.3 versions of the above, those
two artifacts end up using the correct 2.0.3 versions. Still testing so
far. BTW, a few more questions:
dkulp wrote:
Hmm... OK Not sure what to say then although it's probably the same
issue as ServiceMix had on the Mac.
There is a bug in Maven where system properties can overwrite and affect
anything that uses ${project.version} and/or ${pom.version} like we
do.
Questions:
1.) Do you know if the Maven team is aware of this problem--is it in their
JIRA?
2.) Any reason why this might not be occurring with CXF 2.0.2? Or did the
ServiceMix
problem also occur with CXF 2.0.2?
dkulp wrote:
The issue is that some XML parsers or processor (like the one
built into the OSX jvm) has a tendency to set a version system
property which messes that up.Thus, any plugin that does XML
processing at all can cause major issues. Unfortunately, our wsdl2java
plugin does XML processing.
3.) I'm probably exposing my Maven noviceness here, but can CXF be changed
to stop using ${project.version} and ${pom.version} internally then to avoid
this error? If I understand you correctly, as long as CXF avoids these
properties, the problem goes away, correct?
Thanks,
Glen
--
View this message in context:
http://www.nabble.com/Maven-dependency-problem-upgrading-from-CXF-2.0.2-to-2.0.3-tp14921161p14929951.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Maven dependency problem upgrading from CXF 2.0.2 to 2.0.3
Hmm... OK Not sure what to say then although it's probably the
same issue as ServiceMix had on the Mac.
There is a bug in Maven where system properties can overwrite and
affect anything that uses ${project.version} and/or
${pom.version} like we do.
Questions:
1.) Do you know if the Maven team is aware of this problem--is it in
their JIRA?
http://jira.codehaus.org/browse/MNG-2339
and a bunch of duplicates and related issues that are linked to it.
2.) Any reason why this might not be occurring with CXF 2.0.2? Or did
the ServiceMix
problem also occur with CXF 2.0.2?
Well, there are three major changes that may have caused this:
1) Catalog support in the tools - with catalog support, we had to add
some extra XML stuff to the tools to parse/process the catalogs.
2) Validation of the wsdl - 2.0.3 validates the wsdls now to make sure
they really are valid. Again, that's more XML processing.
3) To get (1) working, we had to add all the dependencies to the
classloader that is used when running the plugin. Thus, if your project
depended on a problematic xml parser, with 2.0.2, that wouldn't affect
the plugin running, but with 2.0.3, it might.
ServiceMix was mostly bit by #3 as they were sucking in some old versions
of xerces and such that caused issues.
dkulp wrote:
The issue is that some XML parsers or processor (like the one
built into the OSX jvm) has a tendency to set a version system
property which messes that up.Thus, any plugin that does XML
processing at all can cause major issues. Unfortunately, our
wsdl2java plugin does XML processing.
3.) I'm probably exposing my Maven noviceness here, but can CXF be
changed to stop using ${project.version} and ${pom.version} internally
then to avoid this error? If I understand you correctly, as long as
CXF avoids these properties, the problem goes away, correct?
Possibly, but we'll need to experiment a bit. In particular, the release
process may break. The release plugin currently updates everything that
is needed. I'm not sure if it would update a different property or
not.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
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?
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: Object.toJSON(json),
onSuccess: function(transport,jsonFromHeaders)
and in my beans.xml, I have this:
jaxws:endpoint id=jBoardService
implementor=com.cbs.bos.ws.json.BoardServiceImpl
address=/jBoardService
bindingUri=http://apache.org/cxf/binding/http;
jaxws:properties
entry key=Content-Type value=text/plain/
/jaxws:properties
jaxws:serviceFactory
bean class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
property name=wrapped value=false/
property name=properties
map
entry
keyvaluejavax.xml.stream.XMLInputFactory/value/key
bean class=org.codehaus.jettison.mapped.MappedXMLInputFactory
constructor-arg
map
entry key=http://BoardService.json.bos.cbs.com/;
value=jBoardService/
entry key=http://BoardServiceImpl.json.bos.cbs.com/;
value=jBoardServiceImpl/
/map
/constructor-arg
/bean
/entry
entry
keyvaluejavax.xml.stream.XMLOutputFactory/value/key
bean class=org.codehaus.jettison.mapped.MappedXMLOutputFactory
constructor-arg
map
entry key=http://BoardService.json.bos.cbs.com/;
value=jBoardService/
entry key=http://BoardServiceImpl.json.bos.cbs.com/;
value=jBoardServiceImpl/
/map
/constructor-arg
/bean
/entry
/map
/property
/bean
/jaxws:serviceFactory
/jaxws:endpoint
-Original Message-
From: Liu, Jervis
Re: Validation error using document/literal/wrapped
When you run the java2wsdl, add the -s source-dir and -classdir dir
options. This will cause it to generate wrapper types for the messages
that the validator can use.
Dan
On Thursday 17 January 2008, howesld wrote:
Hi,
I'm doing java to wsdl using cxf 2.0.3 and jaxb 2.0 on Java 5, running
on Tomcat and I have turned on schema validation. I would like to use
document/literal/wrapped, but when I do I get the following error:
Unmarshalling Error: cvc-elt.1: Cannot find the declaration of element
'theInt'.
Here's my interface and class:
@WebService(targetNamespace=http://test.org/;)
public interface IalWebServiceTest {
public void testInt(@WebParam(name=theInt)int myInt) throws
RuntimeException;
}
@WebService(targetNamespace=http://test.org/;)
public class WebServiceTestImpl implements IalWebServiceTest {
public void testInt(int myInt){
System.out.println(myInt = + myInt);
}
}
And my endpoint is configured using spring:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:tx=http://www.springframework.org/schema/tx;
xmlns:aop=http://www.springframework.org/schema/aop;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml/
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
import resource=classpath:META-INF/cxf/cxf-servlet.xml/
tx:annotation-driven transaction-manager=transactionManager/
bean id=ialImpl
class=test.provider.WebServiceTestImpl
/bean
jaxws:endpoint
id=ial
address=/se
implementor=#ialImpl
jaxws:properties
entry key=schema-validation-enabled value=true /
/jaxws:properties
/jaxws:endpoint
/beans
Here's the generated wsdl:
?xml version=1.0 encoding=utf-8?wsdl:definitions
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:tns=http://test.org/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
name=WebServiceTestImplService targetNamespace=http://test.org/;
wsdl:types
xsd:schema attributeFormDefault=unqualified
elementFormDefault=unqualified targetNamespace=http://test.org/;
xmlns:tns=http://test.org/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema; xsd:element
name=testInt type=tns:testInt/
xsd:complexType name=testInt
xsd:sequence
xsd:element name=theInt type=xsd:int/
/xsd:sequence
/xsd:complexType
xsd:element name=testIntResponse type=tns:testIntResponse/
xsd:complexType name=testIntResponse
xsd:sequence/
/xsd:complexType
/xsd:schema
/wsdl:types
wsdl:message name=testIntResponse
wsdl:part element=tns:testIntResponse name=parameters
/wsdl:part
/wsdl:message
wsdl:message name=testInt
wsdl:part element=tns:testInt name=parameters
/wsdl:part
/wsdl:message
wsdl:portType name=IalWebServiceTest
wsdl:operation name=testInt
wsdl:input message=tns:testInt name=testInt
/wsdl:input
wsdl:output message=tns:testIntResponse
name=testIntResponse /wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=WebServiceTestImplServiceSoapBinding
type=tns:IalWebServiceTest
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=testInt
soap:operation soapAction= style=document/
wsdl:input name=testInt
soap:body use=literal/
/wsdl:input
wsdl:output name=testIntResponse
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=WebServiceTestImplService
wsdl:port binding=tns:WebServiceTestImplServiceSoapBinding
name=WebServiceTestImplPort
soap:address location=http://localhost:8080/test/ws/se/
/wsdl:port
/wsdl:service
/wsdl:definitions
Here's a list of the cxf jar's in my project:
cxf-api-2.0.3-incubator.jar
cxf-common-schemas-2.0.3-incubator.jar
cxf-common-utilities-2.0.3-incubator.jar
cxf-rt-bindings-soap-2.0.3-incubator.jar
cxf-rt-bindings-xml-2.0.3-incubator.jar
cxf-rt-core-2.0.3-incubator.jar
cxf-rt-databinding-jaxb-2.0.3-incubator.jar
cxf-rt-frontend-jaxws-2.0.3-incubator.jar
cxf-rt-frontend-simple-2.0.3-incubator.jar
cxf-rt-transports-http-2.0.3-incubator.jar
cxf-rt-ws-security-2.0.3-incubator.jar
cxf-tools-common-2.0.3-incubator.jar
When I use just document/literal (i.e. I add
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) to my
interface and class), I don't get the
Validation error using document/literal/wrapped
Hi,
I'm doing java to wsdl using cxf 2.0.3 and jaxb 2.0 on Java 5, running on
Tomcat and I have turned on schema validation. I would like to use
document/literal/wrapped, but when I do I get the following error:
Unmarshalling Error: cvc-elt.1: Cannot find the declaration of element
'theInt'.
Here's my interface and class:
@WebService(targetNamespace=http://test.org/;)
public interface IalWebServiceTest {
public void testInt(@WebParam(name=theInt)int myInt) throws
RuntimeException;
}
@WebService(targetNamespace=http://test.org/;)
public class WebServiceTestImpl implements IalWebServiceTest {
public void testInt(int myInt){
System.out.println(myInt = + myInt);
}
}
And my endpoint is configured using spring:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:tx=http://www.springframework.org/schema/tx;
xmlns:aop=http://www.springframework.org/schema/aop;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml/
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
import resource=classpath:META-INF/cxf/cxf-servlet.xml/
tx:annotation-driven transaction-manager=transactionManager/
bean id=ialImpl
class=test.provider.WebServiceTestImpl
/bean
jaxws:endpoint
id=ial
address=/se
implementor=#ialImpl
jaxws:properties
entry key=schema-validation-enabled value=true /
/jaxws:properties
/jaxws:endpoint
/beans
Here's the generated wsdl:
?xml version=1.0 encoding=utf-8?wsdl:definitions
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:tns=http://test.org/; xmlns:xsd=http://www.w3.org/2001/XMLSchema;
name=WebServiceTestImplService targetNamespace=http://test.org/;
wsdl:types
xsd:schema attributeFormDefault=unqualified
elementFormDefault=unqualified targetNamespace=http://test.org/;
xmlns:tns=http://test.org/; xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=testInt type=tns:testInt/
xsd:complexType name=testInt
xsd:sequence
xsd:element name=theInt type=xsd:int/
/xsd:sequence
/xsd:complexType
xsd:element name=testIntResponse type=tns:testIntResponse/
xsd:complexType name=testIntResponse
xsd:sequence/
/xsd:complexType
/xsd:schema
/wsdl:types
wsdl:message name=testIntResponse
wsdl:part element=tns:testIntResponse name=parameters
/wsdl:part
/wsdl:message
wsdl:message name=testInt
wsdl:part element=tns:testInt name=parameters
/wsdl:part
/wsdl:message
wsdl:portType name=IalWebServiceTest
wsdl:operation name=testInt
wsdl:input message=tns:testInt name=testInt
/wsdl:input
wsdl:output message=tns:testIntResponse name=testIntResponse
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=WebServiceTestImplServiceSoapBinding
type=tns:IalWebServiceTest
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=testInt
soap:operation soapAction= style=document/
wsdl:input name=testInt
soap:body use=literal/
/wsdl:input
wsdl:output name=testIntResponse
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:service name=WebServiceTestImplService
wsdl:port binding=tns:WebServiceTestImplServiceSoapBinding
name=WebServiceTestImplPort
soap:address location=http://localhost:8080/test/ws/se/
/wsdl:port
/wsdl:service
/wsdl:definitions
Here's a list of the cxf jar's in my project:
cxf-api-2.0.3-incubator.jar
cxf-common-schemas-2.0.3-incubator.jar
cxf-common-utilities-2.0.3-incubator.jar
cxf-rt-bindings-soap-2.0.3-incubator.jar
cxf-rt-bindings-xml-2.0.3-incubator.jar
cxf-rt-core-2.0.3-incubator.jar
cxf-rt-databinding-jaxb-2.0.3-incubator.jar
cxf-rt-frontend-jaxws-2.0.3-incubator.jar
cxf-rt-frontend-simple-2.0.3-incubator.jar
cxf-rt-transports-http-2.0.3-incubator.jar
cxf-rt-ws-security-2.0.3-incubator.jar
cxf-tools-common-2.0.3-incubator.jar
When I use just document/literal (i.e. I add @SOAPBinding(parameterStyle =
SOAPBinding.ParameterStyle.BARE) to my interface and class), I don't get
the error and the message prints to system.out.
Thanks for any help you can give.
--
View this message in context:
http://www.nabble.com/Validation-error-using-document-literal-wrapped-tp14936324p14936324.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF Servlet setup problem
The CXF servlet always looks for WEB-INF/cxf-servlet.xml and loads it. However, it does that after inializing the bus you any imports you have to classpath:META-INF/cxf-. should be removed as they would already be grabbed. Dan On Thursday 17 January 2008, yulinxp wrote: All the sample use the following to start Spring and loads beans.xml file. context-param param-namecontextConfigLocation/param-name param-valueWEB-INF/beans.xml/param-value /context-param listener listener-class org.springframework.web.context.ContextLoaderListener /listener-class /listener In my existing application, there is a customized springLoader in place. Thus I can't use ContextLoaderListener anymore. Neither can I plug in cxf into customized springLoader. Is there any otherway to load beans.xml? I remember in XFire, we only define servlet-class and servlet-mapping, then it will automatically look for META-INF/xfire/services.xml. Can we do that in CXF? how? web-app servlet servlet-nameXFireServlet/servlet-name display-nameXFire Servlet/display-name servlet-class org.codehaus.xfire.transport.http.XFireConfigurableServlet /servlet-class /servlet servlet-mapping servlet-nameXFireServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping /web-app -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: CXF 2.0 client and Websphere 6.1 with WS feature pack
On Thursday 17 January 2008, Rodriguez, Jose wrote: Hi All, I need some help with Websphere 6.1 and CXF. I wrote a Web Services client (using basic authentication) with CXF. I followed these instructions nto setup Websphere: http://cwiki.apache.org/confluence/display/CXF20DOC/AppServerGuide#App ServerGuide-Websphere But I have the same issue than this guy: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=1401773 3 Basically WAS 6.1 checks the annotation and complains about org.apache.cxf.js.rhino.DOMPayloadProvider not implemented in the right way. Is this guy from IBM right? Well, yes and no. For the Axis implementation, yes. He is correct. The spec only mandates that you HAVE to support ProviderSource. (and ProviderSOAPMessage) However, it does allow other Providerfoo things. DOMSource is a specialization for CXF that the axis implementation apparantely doesn't like. Our generated client uses only standard Web services annotations and we have to use a HTTPConduit. Any ideas how to disable this check or to make it works? Well, I guess the only suggestion would be to not use the big cxf-2.0.3-incubator.jar in lib and instead use all the cxf-*-2.0.3-incubator.jar jars in the modules directory EXCEPT for the cxf-rt-frontend-js-2.0.3-incubator.jar that is there. Thus, that specific provider wouldn't be in the jar. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: CXF Servlet setup problem
Yes , here is another way which will not use the org.springframework.web.context.ContextLoaderListener to start the endpoints. You can find the example form CXF's hello world examples [1] As Dan Kulp has said , you don't need imports any of classpath:META-INF/cxf-. [1] https://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/src/main/release/samples/wsdl_first/ Willem. Daniel Kulp wrote: The CXF servlet always looks for WEB-INF/cxf-servlet.xml and loads it. However, it does that after inializing the bus you any imports you have to classpath:META-INF/cxf-. should be removed as they would already be grabbed. Dan On Thursday 17 January 2008, yulinxp wrote: All the sample use the following to start Spring and loads beans.xml file. context-param param-namecontextConfigLocation/param-name param-valueWEB-INF/beans.xml/param-value /context-param listener listener-class org.springframework.web.context.ContextLoaderListener /listener-class /listener In my existing application, there is a customized springLoader in place. Thus I can't use ContextLoaderListener anymore. Neither can I plug in cxf into customized springLoader. Is there any otherway to load beans.xml? I remember in XFire, we only define servlet-class and servlet-mapping, then it will automatically look for META-INF/xfire/services.xml. Can we do that in CXF? how? web-app servlet servlet-nameXFireServlet/servlet-name display-nameXFire Servlet/display-name servlet-class org.codehaus.xfire.transport.http.XFireConfigurableServlet /servlet-class /servlet servlet-mapping servlet-nameXFireServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping /web-app
Still having problems with LocalTransport
My project has a bucketload of JUnit tests that used XFire's 'xfire' Spring
bean to get an XFireProxyFactory object, and create a local instance of the
service.
This code works like this:
XFire xfire = (XFire) applicationContext.getBean(xfire);
ServiceRegistry serviceRegistry = xfire.getServiceRegistry();
Service service = serviceRegistry.getService(name);
XFireProxyFactory factory = new XFireProxyFactory(xfire);
return (WebServiceBase) factory.create(service, xfire.local:// +
name);
I've been trying to get CXF to use the LocalTransport and I think I have it
mostly working - it calls into the service and returns, but the return value
is ALWAYS null. I created a micro-project to test that setup without
anything else in it, and I'm able to re-create the only-null-return issue.
Our stuff uses Spring, JAXWS and Aegis and the configuration file looks like
this:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xmlns:soap=http://cxf.apache.org/bindings/soap;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml/
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
bean id=aegisBean
class=org.apache.cxf.aegis.databinding.AegisDatabinding/
bean id='jaxws-aegis-factory'
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
scope=prototype
property name=dataBinding ref=aegisBean/
property name=serviceConfigurations
list
bean
class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/
bean
class=org.apache.cxf.aegis.databinding.AegisServiceConfiguration/
bean
class=org.apache.cxf.service.factory.DefaultServiceConfiguration/
/list
/property
/bean
bean class=org.apache.cxf.transport.local.LocalTransportFactory
lazy-init=false
property name=transportIds
list
valuehttp://cxf.apache.org/transports/local/value
valuehttp://schemas.xmlsoap.org/soap/http/value
valuehttp://schemas.xmlsoap.org/wsdl/soap/http/value
/list
/property
/bean
jaxws:endpoint name=localtest address=local://localtest
implementor=net.bixbys.svc.CXFLocalTestServiceImpl
jaxws:serviceFactory
ref bean='jaxws-aegis-factory'/
/jaxws:serviceFactory
/jaxws:endpoint
/beans
The interface and implementation of the service:
@WebService(name = ServiceTwo)
public interface CXFLocalTestService {
public String theMethod(String str1, int int2, Long long3);
}
public class CXFLocalTestServiceImpl implements CXFLocalTestService {
public String theMethod(String str1, int int2, Long long3) {
System.out.println(str1 = + str1);
System.out.println(int2 = + int2);
System.out.println(long3 = + long3);
String combined = str1 + -- + int2 + -- + long3;
System.out.println(combined = + combined);
return combined;
}
}
We use Spring dependency injection test classes for our JUnit tests; some
tests use transactional tests so we can modify the DB, and it will roll back
on exit. Other tests just do read-only and skip the transactional part.
The sample's client test:
public class TestLocalService extends
AbstractDependencyInjectionSpringContextTests {
protected String[] getConfigLocations() {
setAutowireMode(AUTOWIRE_BY_NAME);
return new String[]{classpath*:spring-config.xml};
}
public void testServiceCall() throws Exception {
ClientProxyFactoryBean cf = new ClientProxyFactoryBean();
cf.setAddress(local://localtest);
cf.setServiceClass(CXFLocalTestService.class); // Optionally specify
the service interface
CXFLocalTestService lts = (CXFLocalTestService) cf.create();
System.out.println(lts.theMethod(\calling\,10,20L) = +
lts.theMethod(calling, 10, 20L));
}
}
When I run this, I get the console output:
str1 = calling
int2 = 10
long3 = 20
combined = calling -- 10 -- 20
lts.theMethod(calling,10,20L) = null
I've tried stepping into the CXF source, but I don't know my way around very
well. I have no idea if I have a configuration issue, a bug, or what.
Any ideas?
--
View this message in context:
http://www.nabble.com/Still-having-problems-with-LocalTransport-tp14942855p14942855.html
Sent from the cxf-user mailing list archive at Nabble.com.
WebMethod parameter is null - JAXB binding failure?
Hi,
I have been trying to convert the JAXB 2.0 example from XFire to use CXF and
am having trouble with what I believe is a JAXB binding issue. I am using
CVF 2.0.3. I am using the generated JAXB 2.0 java source files from the
XFire example which are annotated. They are not generated with each build,
but instead included in the project source.
When my WeatherServiceImpl class receives the request, the body parameter of
the WebMethod is null. I have included the WeatherService interface and its
implementation. I have also included my configuration file and web.xml. Any
help would be greatly appreciated. I feel like I am not far off from
getting working.
Thanks in advance for any help,
Marc
Here is the WeatherService :
package org.codehaus.xfire.jaxb;
// START SNIPPET: service
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import net.webservicex.GetWeatherByZipCode;
import net.webservicex.GetWeatherByZipCodeResponse;
@WebService(name=WeatherServiceIntf,
targetNamespace=http://www.webservicex.net;)
public interface WeatherService
{
@WebMethod
GetWeatherByZipCodeResponse
GetWeatherByZipCode(@WebParam(name=GetWeatherByZipCode)
GetWeatherByZipCode body);
}
// END SNIPPET: service
Here is the WeatherServiceImpl:
package org.codehaus.xfire.jaxb;
//START SNIPPET: service
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import net.webservicex.GetWeatherByZipCode;
import net.webservicex.GetWeatherByZipCodeResponse;
import net.webservicex.WeatherForecastsType;
/**
* @author mailto:[EMAIL PROTECTED] Dan Diephouse
*/
@WebService(endpointInterface=org.codehaus.xfire.jaxb.WeatherService,
serviceName=WeatherService)
@SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.BARE,use=SOAPBinding.Use.LITERAL)
public class WeatherServiceImpl implements WeatherService
{
public GetWeatherByZipCodeResponse
GetWeatherByZipCode(GetWeatherByZipCode body)
{
GetWeatherByZipCodeResponse res = new GetWeatherByZipCodeResponse();
//THIS NEXT LINE IS WHERE I GET A NULLPOINTEREXCEPTION
String zipCode = body.getZipCode();
WeatherForecastsType weather = new WeatherForecastsType();
weather.setLatitude(1);
weather.setLongitude(1);
weather.setPlaceName(Vienna, AT);
weather.setAllocationFactor(1);
res.setGetWeatherByZipCodeResult(weather);
return res;
}
}
//END SNIPPET: service
Here the web.xml:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
http://java.sun.com/dtd/web-app_2_3.dtd;
web-app
context-param
param-namecontextConfigLocation/param-name
param-value
classpath:cxf-services.xml
/param-value
/context-param
listener
listener-class
org.springframework.web.context.ContextLoaderListener
/listener-class
/listener
servlet
servlet-nameCXFServlet/servlet-name
display-nameCXF Servlet/display-name
servlet-class
org.apache.cxf.transport.servlet.CXFServlet
/servlet-class
/servlet
servlet-mapping
servlet-nameCXFServlet/servlet-name
url-pattern/cxf-services/*/url-pattern
/servlet-mapping
/web-app
Here is my configuration file, cxf-services.xml:
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml /
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml /
import resource=classpath:META-INF/cxf/cxf-servlet.xml /
bean id=theService
class=org.codehaus.xfire.jaxb.WeatherServiceImpl/
bean id=jaxbContext
class=com.rulestream.core.shared.xml.JAXBContextFactoryBean
property name=packages
value=net.webservicex:org.codehaus.xfire.jaxb/
/bean
bean id=jaxbBinding class=org.apache.cxf.jaxb.JAXBDataBinding
property name=context ref=jaxbContext/
/bean
!--
jaxws:endpoint id=serviceSoapEndPoint
implementor=#theService
address=/theService
jaxws:serviceFactory
bean
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
property name=dataBinding ref=jaxbBinding/
property name=serviceConfigurations
list
bean
class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/
bean
class=org.apache.cxf.service.factory.DefaultServiceConfiguration/
/list
/property
/bean
/jaxws:serviceFactory
/jaxws:endpoint
--
jaxws:endpoint
CXFServlet
Me again ... Usually when I create a server I use jetty (pretty simple), I want to move to other container like tomcat. Using the CXFServlet (or the nonSpring servlet) how can I set my data binding to aegis ? ususally I do a sf.getServiceFactory().getServiceConfigurations().add(0, new GroovyConfiguration()); sf.getServiceFactory().setDataBinding(new AegisDatabinding()); Cheers Guillaume
