Nordic charaters problem in SOAP/MQ
I have at problem with sending nordic charaters such as æøå via SOAP over MQ. I'm using cxf version 2.0.1 and SAAJ version 1.3. I have tried to trace where is could go wrong and what I can see, the å looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), but when the SOAPMessage.writeTo() method is called with System.out or OutputStream in SAAJOutInterceptor it is viewed as Ã¥. Can anyone tell me if I can do anything to avoid this behaviour or have it something to do with the SAAJ implementation? -- View this message in context: http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15845741.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: WSDL2Java error when using binding customization
Hi Jim, I tried modifying my WSDL as suggested. However this produces the exact same error as before. The preamble to my WSDL now looks like: http://www.test.com/TestService/"; xmlns:tns="http://www.test.com/TestService/"; xmlns:test="http://www.test.com/test"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns="http://schemas.xmlsoap.org/wsdl/";> http://www.test.com/test"/> ... And the error output looks the same as before: [java] wsdl2java -verbose -client -b bindings.xml -d [...path-to-project ommitted...]/src/main/java [...path-to-project ommitted...]/src/main/test/test.wsdl [java] wsdl2java - Apache CXF (incubator) 2.0.4-incubator [java] WSDLToJava Error : java.lang.RuntimeException: Fail to create wsdl definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl [java] org.apache.cxf.tools.common.ToolException: java.lang.RuntimeException: Fail to create wsdl definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:237) [java] at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83) [java] at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:102) [java] at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:171) [java] Caused by: java.lang.RuntimeException: Fail to create wsdl definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl [java] at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:130) [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:123) [java] at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:229) [java] ... 3 more [java] Caused by: java.lang.RuntimeException: Failed to Resolve types.xsd [java] at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.CustomizedWSDLLocator.getImportInputSource(CustomizedWSDLLocator.java:129) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) [java] at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.buildCustomizedDefinition(JAXWSDefinitionBuilder.java:178) [java] at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:125) [java] ... 5 more [java] Caused by: java.net.URISyntaxException: Illegal character in path at index 53: file: [...path-to-project ommitted...]/src/main/test/test.wsdl [java] at java.net.URI$Parser.fail(URI.java:2816) [java] at java.net.URI$Parser.checkChars(URI.java:2989) [java] at java.net.URI$Parser.parseHierarchical(URI.java:3073) [java] at java.net.URI$Parser.parse(URI.java:3021) [java] at java.net.URI.(URI.java:578) [java] at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.CustomizedWSDLLocator.getImportInputSource(CustomizedWSDLLocator.java:113) [java] ... 16 more Is this being caused by a bug somewhere in WSDL2Java? As before, it all works OK if the binding file is not passed in. Thanks, Jesse. jim ma wrote: > > Some elements are missing in your wsdl. Can you modify your wsdl like this > and try it again ? > > > targetNamespace="http://www.test.com/TestService/"; >xmlns:tns="http://www.test.com/TestService/"; >xmlns:test="http://www.test.com/test"; >xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; >xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >xmlns="http://schemas.xmlsoap.org/wsdl/";> > > > http://www.test.com/test"/> > > > > > > > On Wed, Mar 5, 2008 at 1:51 AM, Jesse McLaughlin <[EMAIL PROTECTED]> > wrote: > >> >> OK, thanks for the tip about the verbose flag. I got the stack trace >> output >> now: >> >> [java] wsdl2java -verbose -client -b bindings.xml -d >> [...path-to-project ommitted...]/src/main/java [...path-to-project >> ommitted...]/src/main/test/test.wsdl >> [java] wsdl2java - Apache CXF (incubator) 2.0.4-incubator >> [java] WSDLToJava Error : java.lang.RuntimeException: Fail to create >> wsdl definition f
HTTPs and CXF
Hello, I see the topic of HTTPs has been discussed very recently, however has there been a conclusion? I've created a CXF client stub that operates correctly with HTTP, but when I do nothing more than change the location in the WSDL to an HTTPs URL, and generate stubs, I receive the following runtime exception: Caused by: java.io.IOException: Illegal Protocol https for HTTP URLConnection Factory. at org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConnection(HttpURLConnectionFactoryImpl.java:44) at org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474) at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) ... 8 more Is this a bug? Surely CXF is able to handle an HTTPs URL? If it's not a bug, what am I expected to do? Thanks, John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: HTTPs and CXF
Isn't that an awful lot of effort? Shouldn't it "just work" like any other application in the world? John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com "Christian Vest Hansen" <[EMAIL PROTECTED]> 05/03/2008 10:43 Please respond to cxf-user@incubator.apache.org To cxf-user@incubator.apache.org cc Subject Re: HTTPs and CXF You are expected to configure a http conduit so that it will make proper use of SSL: http://cwiki.apache.org/CXF20DOC/client-http-transport.html :) On 3/5/08, John-M Baker <[EMAIL PROTECTED]> wrote: > Hello, > > I see the topic of HTTPs has been discussed very recently, however has > there been a conclusion? I've created a CXF client stub that operates > correctly with HTTP, but when I do nothing more than change the location > in the WSDL to an HTTPs URL, and generate stubs, I receive the following > runtime exception: > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > URLConnection Factory. > at > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConnection(HttpURLConnectionFactoryImpl.java:44) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 8 more > > Is this a bug? Surely CXF is able to handle an HTTPs URL? If it's not a > bug, what am I expected to do? > > Thanks, > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -- Venlig hilsen / Kind regards, Christian Vest Hansen. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: HTTPs and CXF
You are expected to configure a http conduit so that it will make proper use of SSL: http://cwiki.apache.org/CXF20DOC/client-http-transport.html :) On 3/5/08, John-M Baker <[EMAIL PROTECTED]> wrote: > Hello, > > I see the topic of HTTPs has been discussed very recently, however has > there been a conclusion? I've created a CXF client stub that operates > correctly with HTTP, but when I do nothing more than change the location > in the WSDL to an HTTPs URL, and generate stubs, I receive the following > runtime exception: > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > URLConnection Factory. > at > > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConnection(HttpURLConnectionFactoryImpl.java:44) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474) > at > > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46) > ... 8 more > > Is this a bug? Surely CXF is able to handle an HTTPs URL? If it's not a > bug, what am I expected to do? > > Thanks, > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and delete this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. -- Venlig hilsen / Kind regards, Christian Vest Hansen.
Code Fisrt + JSON: xmlbinding problem
Hi all. I'm trying to use CXF as backed for a web base application (Flex). Cxf has to expose json over http endpoint. The approach should be “code first” instead “wsdl first” for speeding up the development process. CXF has some problem with this (or maybe I was not able to run it properly), the problem is related with the xmlbinding. Did someone have the same experience? I have created a test case, how I could share it? Do I send it to this mailing list? Thanks, Luca. P.S. The problem happens with: 2.0-incubator 2.0.4-incubator 2.0.4.0-fuse 2.1-incubator-SNAPSHOT ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
Re: WSDL2Java error when using binding customization
I tried it in command line and it works. I notice this error message : Caused by: java.net.URISyntaxException: Illegal character in path at index 53: file: [...path-to-project ommitted...]/src/main/test/test.wsdl. Is there any strange character in this path ? On 3/5/08, Jesse McLaughlin <[EMAIL PROTECTED]> wrote: > > Hi Jim, > > I tried modifying my WSDL as suggested. However this produces the exact > same error as before. The preamble to my WSDL now looks like: > > > targetNamespace="http://www.test.com/TestService/"; > xmlns:tns="http://www.test.com/TestService/"; > xmlns:test="http://www.test.com/test"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > xmlns="http://schemas.xmlsoap.org/wsdl/";> > > > > namespace="http://www.test.com/test"/> > > > > ... > > And the error output looks the same as before: > > [java] wsdl2java -verbose -client -b bindings.xml -d [...path-to-project > ommitted...]/src/main/java [...path-to-project > ommitted...]/src/main/test/test.wsdl > [java] wsdl2java - Apache CXF (incubator) 2.0.4-incubator > [java] WSDLToJava Error : java.lang.RuntimeException: Fail to create wsdl > definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl > [java] org.apache.cxf.tools.common.ToolException: > java.lang.RuntimeException: Fail to create wsdl definition file: > [...path-to-project ommitted...]/src/main/test/test.wsdl > [java] at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:237) > [java] at > org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83) > [java] at > org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:102) > [java] at > org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:171) > [java] Caused by: java.lang.RuntimeException: Fail to create wsdl > definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl > [java] at > org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:130) > [java] at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:123) > [java] at > org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:229) > [java] ... 3 more > [java] Caused by: java.lang.RuntimeException: Failed to Resolve types.xsd > [java] at > org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.CustomizedWSDLLocator.getImportInputSource(CustomizedWSDLLocator.java:129) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown > Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) > [java] at > org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.buildCustomizedDefinition(JAXWSDefinitionBuilder.java:178) > [java] at > org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:125) > [java] ... 5 more > [java] Caused by: java.net.URISyntaxException: Illegal character in path at > index 53: file: [...path-to-project ommitted...]/src/main/test/test.wsdl > [java] at java.net.URI$Parser.fail(URI.java:2816) > [java] at java.net.URI$Parser.checkChars(URI.java:2989) > [java] at java.net.URI$Parser.parseHierarchical(URI.java:3073) > [java] at java.net.URI$Parser.parse(URI.java:3021) > [java] at java.net.URI.(URI.java:578) > [java] at > org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.CustomizedWSDLLocator.getImportInputSource(CustomizedWSDLLocator.java:113) > [java] ... 16 more > > > Is this being caused by a bug somewhere in WSDL2Java? As before, it all > works OK if the binding file is not passed in. > > Thanks, > Jesse. > > > > jim ma wrote: > > > > Some elements are missing in your wsdl. Can you modify your wsdl like this > > and try it again ? > > > > > > >targetNamespace="http://www.test.com/TestService/"; > >xmlns:tns="http://www.test.com/TestService/"; > >xmlns:test="http://www.test.com/test"; > >xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > >xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > >xmlns="http://schemas.xmlsoap.org/wsdl/";> > > > > > > http://www.test.com/test"/> > > > > > > > > > > > > > > On Wed, Mar 5, 2008 at
Re: Nordic charaters problem in SOAP/MQ
Hmm, could'nt you just escape it(that would be soft fix)? this might be a dumb question, but which kind of encoding do you use on your files? Or are the chars fetched/passed dynamically via db etc? regards Nino mr.andersen wrote: I have at problem with sending nordic charaters such as æøå via SOAP over MQ. I'm using cxf version 2.0.1 and SAAJ version 1.3. I have tried to trace where is could go wrong and what I can see, the å looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), but when the SOAPMessage.writeTo() method is called with System.out or OutputStream in SAAJOutInterceptor it is viewed as Ã¥. Can anyone tell me if I can do anything to avoid this behaviour or have it something to do with the SAAJ implementation? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684
Re: Code Fisrt + JSON: xmlbinding problem
You could fill a jira and attach the test case with it. Willem On 3/5/08, Luca Ceppelli <[EMAIL PROTECTED]> wrote: > > > Hi all. > > > I'm trying to use CXF as > backed for a web base application (Flex). Cxf has to expose json over > http endpoint. The approach should be "code first" instead "wsdl > first" for speeding up the development process. > > > CXF has some problem with > this (or maybe I was not able to run it properly), the problem is > related with the xmlbinding. Did someone have the same experience? > I have created a test > case, how I could share it? Do I send it to this mailing list? > > > > > Thanks, > Luca. > > > P.S. The problem happens > with: > > > 2.0-incubator > 2.0.4-incubator > 2.0.4.0-fuse > 2.1-incubator-SNAPSHOT > > > > > > > ___ > L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: > http://it.docs.yahoo.com/nowyoucan.html >
CXF REST problems
Hi there,
I've been looking through the user group and I haven't been able to find an
answer to my problem so I thought I'd send a post and see if anyone can help
me.
I downloaded the 20080228 and the 20080303 snapshots. What I describe below
are problems that I have found in both.
First problem that I've noticed is that I can't find the @UriTemplate
annotation. It's not in the jsr311-api-0.5.jar file where all of the other
JSR annotations can be found. So, I had a look at the JSR spec, and the
@Path annotation seemed appropriate so I used that instead. Is that correct?
Second problem is that I implemented a service using the @Path annotation
and I'm getting a null pointer exception as described below. I am using
spring configuration, so here's my spring config file:
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxrs="http://cxf.apache.org/jaxrs";
xmlns:cxf="http://cxf.apache.org/core";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/bindings/soap
http://cxf.apache.org/schemas/configuration/soap.xsd
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd";>
Here's the resource file:
@Path("/emitterResource")
public class EmitterResource {
@Path("/getEmitters")
public Collection getEmitters() {
return emitterDAO.getAllEmitters();
}
@Path("/emitters/{emitterId}")
public Emitter getEmitter(@QueryParam("emitterId") int id) {
//public Emitter getEmitter(@WebParam(name = "emitterId") int id) {
LOG.debug("looking for emitter id " + id);
return emitterDAO.get(id);
}
@Path("/emitters")
public void addEmitter(@QueryParam("emitter")Emitter emitter) {
LOG.warn("Adding an emitter");
LOG.warn("ID is " + emitter.getId());
LOG.warn("Name is " + emitter.getName());
emitterDAO.save(emitter);
}
When I try to add @HttpMethod annotations above the @Path annotations I get
the error "The annotation @HttpMethod is disallowed for this location"
The Emitter class is just a POJO with an Id and a Name.
Here's a snippet of my client code (I'm using apache commons HttpClient) :
Emitter e = new Emitter();
e.setId(12345);
e.setName("Test Name");
PostMethod post = new
PostMethod("http://localhost:8080/emitterResource/emitters";);
StringWriter stringWriter = new StringWriter();
jaxbMarshaller.marshal(registryObject, stringWriter);
StringRequestEntity requestEntity = new
StringRequestEntity(stringWriter.toString(), "text/xml", "ISO-8859-1");
post.setRequestEntity(requestEntity);
HttpClient httpClient = new HttpClient();
int result = httpClient.executeMethod(post);
System.out.println("Response code " + result);
System.out.println(post.getResponseBodyAsString());
post.releaseConnection();
I'm deploying the server in tomcat 5.5 successfully (no errors), but when I
run the client, I'm getting the following exception:
05-Mar-2008 11:08:39 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
FINE: Invoking handleMessage on interceptor
[EMAIL PROTECTED]
05-Mar-2008 11:08:39 org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor
handleMessage
FINE: Request path is: /emitterResource/emitters/
05-Mar-2008 11:08:39 org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor
handleMessage
FINE: Request HTTP method is: POST
05-Mar-2008 11:08:39 org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor
handleMessage
FINE: Request contentType is: text/xml; charset=ISO-8859-1
05-Mar-2008 11:08:39 org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor
handleMessage
FINE: Accept contentType is: */*
05-Mar-2008 11:08:39 org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor
handleMessage
INFO: Found operation: getEmitter
05-Mar-2008 11:08:39 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:415)
at java.lang.Integer.valueOf(Integer.java:553)
at
org.apache.cxf.common.util.PrimitiveUtils.read(PrimitiveUtils.java:60)
at org.apache.cxf.jaxrs.JAXRSUtils.readQueryString(JAXRSUtils.java:295)
at org.apache.cxf.jaxrs.JAXRSUtils.processParameter(JAXRSUtils.java:277)
at
org.apache.cxf.jaxrs.JAXRSUtils.processParameters(JAXRSUtils.java:241)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:112)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
JIRA CXF-1456
Hello,
Is there a fix to http://issues.apache.org/jira/browse/CXF-1456 for CXF
2.0.4? Or should I ask, when is 2.0.5 going to be released?
Also, on the subject of SSL, this is far too much effort:
HTTPConduit http = (HTTPConduit)cxfClient.getConduit();
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.setSecureSocketProtocol("SSL");
http.setTlsClientParameters(tlsParams);
Could CXF not automatically handle SSL in 2.0.5? A URL with https should
not cause CXF to require extra coding!
Thanks,
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional
EU corporate and regulatory disclosures.
Re: CXF REST problems
Hi
> First problem that I've noticed is that I can't find the @UriTemplate
> annotation. It's not in the jsr311-api-0.5.jar file where all of the other
> JSR annotations can be found. So, I had a look at the JSR spec, and the
> @Path annotation seemed appropriate so I used that instead. Is that correct?
Yes, 0.5 replaced @UriTemplate with @Path
> Second problem is that I implemented a service using the @Path annotation
> and I'm getting a null pointer exception as described below.
It's a NumberFormatException there, and it's caused by the fact there's no
expected QueryParam in a request.
You need to use @UriParam instead (please note in 0.6 it will be replaced with
@PathParam), see below...
> When I try to add @HttpMethod annotations above the @Path annotations I get
> the error "The annotation @HttpMethod is disallowed for this location"
Yes, starrting from 0.5 one can use @HttpMethod to create designators, sucg as
@GET/@[EMAIL PROTECTED]/@DELETE,
so you may for example create @GetRequest if you think it's better than @GET or
create designators for other http methods
Here's the class :
@Path("/emitterResource")
public class EmitterResource {
@GET
@Path("/getEmitters")
public Collection getEmitters() {
return emitterDAO.getAllEmitters();
}
@GET
@Path("/emitters/{emitterId}")
public Emitter getEmitter(@UriParam("emitterId") int id) {
LOG.debug("looking for emitter id " + id);
return emitterDAO.get(id);
}
}
You might want to chnage it like this to minimize a bit the numbner of
annotations :
@Path("/emitters")
public class EmitterResource {
@GET
public Collection getEmitters() {
return emitterDAO.getAllEmitters();
}
@GET
@Path("{emitterId}")
public Emitter getEmitter(@UriParam("emitterId") int id) {
LOG.debug("looking for emitter id " + id);
return emitterDAO.get(id);
}
}
Hope it helps
Cheers, Sergey
>
> Hi there,
>
> I've been looking through the user group and I haven't been able to find an
> answer to my problem so I thought I'd send a post and see if anyone can help
> me.
>
> I downloaded the 20080228 and the 20080303 snapshots. What I describe below
> are problems that I have found in both.
>
> First problem that I've noticed is that I can't find the @UriTemplate
> annotation. It's not in the jsr311-api-0.5.jar file where all of the other
> JSR annotations can be found. So, I had a look at the JSR spec, and the
> @Path annotation seemed appropriate so I used that instead. Is that correct?
>
> Second problem is that I implemented a service using the @Path annotation
> and I'm getting a null pointer exception as described below. I am using
> spring configuration, so here's my spring config file:
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxrs="http://cxf.apache.org/jaxrs";
> xmlns:cxf="http://cxf.apache.org/core";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> http://cxf.apache.org/bindings/soap
> http://cxf.apache.org/schemas/configuration/soap.xsd
> http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd";>
>
>
> />
>
>
>
>
>
>
>
>
>
> Here's the resource file:
>
> @Path("/emitterResource")
> public class EmitterResource {
>
>@Path("/getEmitters")
>public Collection getEmitters() {
>return emitterDAO.getAllEmitters();
>}
>
>@Path("/emitters/{emitterId}")
>public Emitter getEmitter(@QueryParam("emitterId") int id) {
>//public Emitter getEmitter(@WebParam(name = "emitterId") int id) {
> LOG.debug("looking for emitter id " + id);
> return emitterDAO.get(id);
>}
>
>@Path("/emitters")
>public void addEmitter(@QueryParam("emitter")Emitter emitter) {
>LOG.warn("Adding an emitter");
>LOG.warn("ID is " + emitter.getId());
>LOG.warn("Name is " + emitter.getName());
>emitterDAO.save(emitter);
>}
>
> When I try to add @HttpMethod annotations above the @Path annotations I get
> the error "The annotation @HttpMethod is disallowed for this location"
>
> The Emitter class is just a POJO with an Id and a Name.
>
> Here's a snippet of my client code (I'm using apache commons HttpClient) :
>
> Emitter e = new Emitter();
> e.setId(12345);
> e.setName("Test Name");
> PostMethod post = new
> PostMethod("http://localhost:8080/emitterResource/emitters";);
>
>StringWriter stringWriter = new StringWriter();
>jaxbMarshaller.marshal(registryObject, stringWriter);
>
>StringRequestEntity requestEntity = new
> StringRequestEntity(stringWriter.toString(), "text/xml", "ISO-8859-1");
>post.setRequestEntity(requestEntit
Re: Nordic charaters problem in SOAP/MQ
The idea of escaping the characters is not possible, since the reciever doesn't expect that. The text I'm trying to send throw cxf is hardcoded at this point. About the encoding for my files - do you mean java files or du you assume my text was being read from a file? Nino.Martinez wrote: > > Hmm, could'nt you just escape it(that would be soft fix)? > > > this might be a dumb question, but which kind of encoding do you use on > your files? Or are the chars fetched/passed dynamically via db etc? > > regards Nino > > mr.andersen wrote: >> I have at problem with sending nordic charaters such as æøå via SOAP over >> MQ. >> I'm using cxf version 2.0.1 and SAAJ version 1.3. >> >> I have tried to trace where is could go wrong and what I can see, the å >> looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), >> but >> when the SOAPMessage.writeTo() method is called with System.out or >> OutputStream in SAAJOutInterceptor it is viewed as Ã¥. >> >> Can anyone tell me if I can do anything to avoid this behaviour or have >> it >> something to do with the SAAJ implementation? >> >> > > -- > -Wicket for love > -Jme for fun > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > > > -- View this message in context: http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15848433.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: Nordic charaters problem in SOAP/MQ
In every other area, CXF writes UTF-8. Are you expecting UTF-8, or something else? On Wed, Mar 5, 2008 at 4:00 AM, mr.andersen <[EMAIL PROTECTED]> wrote: > > I have at problem with sending nordic charaters such as æøå via SOAP over > MQ. > I'm using cxf version 2.0.1 and SAAJ version 1.3. > > I have tried to trace where is could go wrong and what I can see, the å > looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), but > when the SOAPMessage.writeTo() method is called with System.out or > OutputStream in SAAJOutInterceptor it is viewed as Ã¥. > > Can anyone tell me if I can do anything to avoid this behaviour or have it > something to do with the SAAJ implementation? > > -- > View this message in context: > http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15845741.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
RE: HTTPs and CXF
Yes, for clients who have no strong requirements for SSL themselves (i.e. are happy to use insecure HTTP if they ca get away with it) it would be reasonable to expect to be able to use SSL without being required to have per-conduit config if the other required SSL config was defaulted or otherwise specified at a higher level (or via appropriate defaults). Every SSL application in the world does have SSL configuration its just a matter of how its picked up :-) --- However for clients that DO have specific security requirements one would also want to be able to enforce the use of SSL in some fashion. For these types of secure apps though : basing the decision purely on the URL which might even have been retrieved dynamically over an insecure connection would be inappropriate. In general this (fairly typical) type of secure application would like to be able to specify this type of strictly secure behaviour at a high level (not per conduit/endpoint). Cheers, Donal -Original Message- From: John-M Baker [mailto:[EMAIL PROTECTED] Sent: 05 March 2008 10:44 To: cxf-user@incubator.apache.org Cc: cxf-user@incubator.apache.org Subject: Re: HTTPs and CXF Isn't that an awful lot of effort? Shouldn't it "just work" like any other application in the world? John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com "Christian Vest Hansen" <[EMAIL PROTECTED]> 05/03/2008 10:43 Please respond to cxf-user@incubator.apache.org To cxf-user@incubator.apache.org cc Subject Re: HTTPs and CXF You are expected to configure a http conduit so that it will make proper use of SSL: http://cwiki.apache.org/CXF20DOC/client-http-transport.html :) On 3/5/08, John-M Baker <[EMAIL PROTECTED]> wrote: > Hello, > > I see the topic of HTTPs has been discussed very recently, however has > there been a conclusion? I've created a CXF client stub that operates > correctly with HTTP, but when I do nothing more than change the location > in the WSDL to an HTTPs URL, and generate stubs, I receive the following > runtime exception: > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > URLConnection Factory. > at > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConnect ion(HttpURLConnectionFactoryImpl.java:44) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Messag eSenderInterceptor.java:46) > ... 8 more > > Is this a bug? Surely CXF is able to handle an HTTPs URL? If it's not a > bug, what am I expected to do? > > Thanks, > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -- Venlig hilsen / Kind regards, Christian Vest Hansen. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: HTTPs and CXF
I'm not arguing that there shouldn't be a mechanism to improve the SSL configuration, I'm suggesting that the product is overly difficult to use becasue it does not support basic SSL out of the box - which is the basic requirement for most people. Given I found myself researching this issue by reading a post only a few days old, from someone who was equally puzzled that effort was required to use an HTTPs URL, I can not help thinking CXF should support basic SSL out of the box. Write a little warning to the logs if you must, but introducing effort for something so common place does not make life easier for the developer. It only cost me a morning of my time, and I'm still not finished because of the cipher bug... John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com "Arundel, Donal" <[EMAIL PROTECTED]> 05/03/2008 12:11 Please respond to cxf-user@incubator.apache.org To cc Subject RE: HTTPs and CXF Yes, for clients who have no strong requirements for SSL themselves (i.e. are happy to use insecure HTTP if they ca get away with it) it would be reasonable to expect to be able to use SSL without being required to have per-conduit config if the other required SSL config was defaulted or otherwise specified at a higher level (or via appropriate defaults). Every SSL application in the world does have SSL configuration its just a matter of how its picked up :-) --- However for clients that DO have specific security requirements one would also want to be able to enforce the use of SSL in some fashion. For these types of secure apps though : basing the decision purely on the URL which might even have been retrieved dynamically over an insecure connection would be inappropriate. In general this (fairly typical) type of secure application would like to be able to specify this type of strictly secure behaviour at a high level (not per conduit/endpoint). Cheers, Donal -Original Message- From: John-M Baker [mailto:[EMAIL PROTECTED] Sent: 05 March 2008 10:44 To: cxf-user@incubator.apache.org Cc: cxf-user@incubator.apache.org Subject: Re: HTTPs and CXF Isn't that an awful lot of effort? Shouldn't it "just work" like any other application in the world? John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com "Christian Vest Hansen" <[EMAIL PROTECTED]> 05/03/2008 10:43 Please respond to cxf-user@incubator.apache.org To cxf-user@incubator.apache.org cc Subject Re: HTTPs and CXF You are expected to configure a http conduit so that it will make proper use of SSL: http://cwiki.apache.org/CXF20DOC/client-http-transport.html :) On 3/5/08, John-M Baker <[EMAIL PROTECTED]> wrote: > Hello, > > I see the topic of HTTPs has been discussed very recently, however has > there been a conclusion? I've created a CXF client stub that operates > correctly with HTTP, but when I do nothing more than change the location > in the WSDL to an HTTPs URL, and generate stubs, I receive the following > runtime exception: > > Caused by: java.io.IOException: Illegal Protocol https for HTTP > URLConnection Factory. > at > org.apache.cxf.transport.http.HttpURLConnectionFactoryImpl.createConnect ion(HttpURLConnectionFactoryImpl.java:44) > at > org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:474) > at > org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(Messag eSenderInterceptor.java:46) > ... 8 more > > Is this a bug? Surely CXF is able to handle an HTTPs URL? If it's not a > bug, what am I expected to do? > > Thanks, > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -- Venlig hilsen / Kind regards, Christian Vest Hansen. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland --- This e-mail may contain confidential and/or privileged info
Re: Nordic charaters problem in SOAP/MQ
I'm expecting UTF-8 since the reciever expects that I live up to WS-I Basic Profile. And it's also my understanding that CXF uses UTF-8 all the way, but I cannot understand why my å is converted to Ã¥ when SOAPMessage.writeTo() is used. Benson Margulies-4 wrote: > > In every other area, CXF writes UTF-8. Are you expecting UTF-8, or > something > else? > > On Wed, Mar 5, 2008 at 4:00 AM, mr.andersen <[EMAIL PROTECTED]> wrote: > >> >> I have at problem with sending nordic charaters such as æøå via SOAP over >> MQ. >> I'm using cxf version 2.0.1 and SAAJ version 1.3. >> >> I have tried to trace where is could go wrong and what I can see, the å >> looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), >> but >> when the SOAPMessage.writeTo() method is called with System.out or >> OutputStream in SAAJOutInterceptor it is viewed as Ã¥. >> >> Can anyone tell me if I can do anything to avoid this behaviour or have >> it >> something to do with the SAAJ implementation? >> >> -- >> View this message in context: >> http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15845741.html >> Sent from the cxf-user mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15848926.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF REST problems
Hi, and thanks for your reply. I have tried your suggestion, I changed the
@QueryParam to @UriParam and now I get a different error. Here's the updated
method:
@POST
@Path("/emitters")
public void addEmitter(@UriParam("emitter")Emitter emitter) {
LOG.warn("Adding an emitter");
LOG.warn("ID is " + emitter.getId()); <- NullPointerException on
this line
LOG.warn("Name is " + emitter.getName());
emitterDAO.save(emitter);
}
This is the NullPointerException exception:
FINE: Invoking handleMessage on interceptor
[EMAIL PROTECTED]
05-Mar-2008 12:25:05 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
FINE: Application has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault
at
org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:107)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:95)
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:62)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:113)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.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(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at
com.westglobal.mscape.registry.EmitterResource.addEmitter(EmitterResource.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:124)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:82)
... 27 more
All other code/content is as per my previous message.
Thanks again!
daveor
--
View this message in context:
http://www.nabble.com/CXF-REST-problems-tp15848325p15849017.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Nordic charaters problem in SOAP/MQ
mr.andersen wrote: The idea of escaping the characters is not possible, since the reciever doesn't expect that. I guess both sender and reciver should expect it.. Okay no go for this then... The text I'm trying to send throw cxf is hardcoded at this point. About the encoding for my files - do you mean java files or du you assume my text was being read from a file? I actually assumed, that you were testing this directly from your java source.. I've had some trouble in other projects where encoding were set by eclipse, forexample macroman, or windows cp... This could probably cause trouble aswell.. Nino.Martinez wrote: Hmm, could'nt you just escape it(that would be soft fix)? this might be a dumb question, but which kind of encoding do you use on your files? Or are the chars fetched/passed dynamically via db etc? regards Nino mr.andersen wrote: I have at problem with sending nordic charaters such as æøå via SOAP over MQ. I'm using cxf version 2.0.1 and SAAJ version 1.3. I have tried to trace where is could go wrong and what I can see, the å looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), but when the SOAPMessage.writeTo() method is called with System.out or OutputStream in SAAJOutInterceptor it is viewed as Ã¥. Can anyone tell me if I can do anything to avoid this behaviour or have it something to do with the SAAJ implementation? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684
Re: Nordic charaters problem in SOAP/MQ
Nino Saturnino Martinez Vazquez Wael wrote: mr.andersen wrote: The idea of escaping the characters is not possible, since the reciever doesn't expect that. I guess both sender and reciver should expect it.. Okay no go for this then... Just thought of something though, you could try to send the char as an escaped unicode. like this : stringIwanttosend+= \u00C6 ; That should append æ... The text I'm trying to send throw cxf is hardcoded at this point. About the encoding for my files - do you mean java files or du you assume my text was being read from a file? I actually assumed, that you were testing this directly from your java source.. I've had some trouble in other projects where encoding were set by eclipse, forexample macroman, or windows cp... This could probably cause trouble aswell.. Nino.Martinez wrote: Hmm, could'nt you just escape it(that would be soft fix)? this might be a dumb question, but which kind of encoding do you use on your files? Or are the chars fetched/passed dynamically via db etc? regards Nino mr.andersen wrote: I have at problem with sending nordic charaters such as æøå via SOAP over MQ. I'm using cxf version 2.0.1 and SAAJ version 1.3. I have tried to trace where is could go wrong and what I can see, the å looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), but when the SOAPMessage.writeTo() method is called with System.out or OutputStream in SAAJOutInterceptor it is viewed as Ã¥. Can anyone tell me if I can do anything to avoid this behaviour or have it something to do with the SAAJ implementation? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684
Re: CXF REST problems
Hi,
In this case what happens is that no MessageBodyReader (provider capable of
getting the input stream data and turning them into Emitter object) has been
found, thus it's a null and it's an application level error. That said, I need
to check what the spec says about it, perhaps an exception shouild be raised
earlier...
What is an Emmiter class ? Is it annotated with JAXB annotatations such as
@XmlRootElement ?
Does GET works for you, that is can you retrieve an individual Emitter from a
browser ?
If Emitters are not JAXB-aware then you'd need to register a custom Emitter
provider, which would know how to serialize/deserialize them. Alertantive you
might want to use JAXP Source and deal with XML locally...
Actually, I've written it all and just realized that your annotations are not
correct :
>@POST
>@Path("/emitters/")
>public void addEmitter(@UriParam("emitter")Emitter emitter) {
One can annotate with @UriParam only those parameters which are supposed to be
substituted as template variables found in your @Path, for ex :
@PUT
@Path("/emitters/{id}")
public void addEmitter(@UriParam("id") String id, Emitter emitter) {
}
So in your case doing just
@POST
@Path("/emitters")
public void addEmitter(Emitter emitter) {
}
should work fine, provided your Emitter is JAXB-aware :-)
Give it a try please,
Cheers, Sergey
- Original Message -
From: "daveor" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 05, 2008 12:37 PM
Subject: Re: CXF REST problems
>
> Hi, and thanks for your reply. I have tried your suggestion, I changed the
> @QueryParam to @UriParam and now I get a different error. Here's the updated
> method:
>
>@POST
>@Path("/emitters")
>public void addEmitter(@UriParam("emitter")Emitter emitter) {
>LOG.warn("Adding an emitter");
>LOG.warn("ID is " + emitter.getId()); <- NullPointerException on
> this line
>LOG.warn("Name is " + emitter.getName());
>emitterDAO.save(emitter);
>}
>
>
> This is the NullPointerException exception:
>
> FINE: Invoking handleMessage on interceptor
> [EMAIL PROTECTED]
> 05-Mar-2008 12:25:05 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:107)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:95)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:62)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:113)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.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(ApplicationFilterChain.java:269)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> at
> com.westglobal.mscape.registry.Emitt
Re: Nordic charaters problem in SOAP/MQ
Nino Saturnino Martinez Vazquez Wael wrote: Nino Saturnino Martinez Vazquez Wael wrote: mr.andersen wrote: The idea of escaping the characters is not possible, since the reciever doesn't expect that. I guess both sender and reciver should expect it.. Okay no go for this then... Just thought of something though, you could try to send the char as an escaped unicode. like this : stringIwanttosend+= \u00C6 ; That should append æ... With that I mean that you dont have to worry about your file encoding... If it's something system wise it'll produce the exact same error... The text I'm trying to send throw cxf is hardcoded at this point. About the encoding for my files - do you mean java files or du you assume my text was being read from a file? I actually assumed, that you were testing this directly from your java source.. I've had some trouble in other projects where encoding were set by eclipse, forexample macroman, or windows cp... This could probably cause trouble aswell.. Nino.Martinez wrote: Hmm, could'nt you just escape it(that would be soft fix)? this might be a dumb question, but which kind of encoding do you use on your files? Or are the chars fetched/passed dynamically via db etc? regards Nino mr.andersen wrote: I have at problem with sending nordic charaters such as æøå via SOAP over MQ. I'm using cxf version 2.0.1 and SAAJ version 1.3. I have tried to trace where is could go wrong and what I can see, the å looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), but when the SOAPMessage.writeTo() method is called with System.out or OutputStream in SAAJOutInterceptor it is viewed as Ã¥. Can anyone tell me if I can do anything to avoid this behaviour or have it something to do with the SAAJ implementation? -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 -- -Wicket for love -Jme for fun Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684
Re: CXF & Spring Transactions
I have found the root of the problem, which fortunately isn't CXF related but a Spring-AOP (AspectJ) problem. Thanks. -- View this message in context: http://www.nabble.com/CXF---Spring-Transactions-tp15814197p15850223.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF REST problems
Hey hey!
Removing the @UriParam did the trick!
@POST
@Path("/emitters")
public void addEmitter(Emitter emitter) {
}
thanks for the help!
--
View this message in context:
http://www.nabble.com/CXF-REST-problems-tp15848325p15850224.html
Sent from the cxf-user mailing list archive at Nabble.com.
Contract-last, empty List null
I've checked the response from my server side web service method. It is indeed not null and empty. But the client gets a null object back. I tried using the CXF 2.1-SNAPSHOT (for JAXB 2.1) but I couldn't get my services to work. What else can I try short of writing XSDs? -- View this message in context: http://www.nabble.com/Contract-last%2C-empty-List-null-tp15850232p15850232.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: WSDL2Java error when using binding customization
Hi Jim, No, there's no strange characters in the full path. There are spaces, but that's about as strange as it gets. Keep in mind that everything works without error if I leave out the binding file, so I'm confident the WSDL is valid, etc. etc. And as I mentioned earlier, I was able to use my original binding file as long as I inlined the XSD, rather than import it. It is only when I import the XSD *and* pass in the binding file that it doesn't work and I get this error. I'm a bit stuck as to where to go from here. Should I report this as a bug? The only problem with that is that it may well not be a bug! Thanks, Jesse. jim ma wrote: > > I tried it in command line and it works. > I notice this error message : > > Caused by: java.net.URISyntaxException: Illegal character in path at > index 53: file: [...path-to-project ommitted...]/src/main/test/test.wsdl. > > Is there any strange character in this path ? > > > > On 3/5/08, Jesse McLaughlin <[EMAIL PROTECTED]> wrote: >> >> Hi Jim, >> >> I tried modifying my WSDL as suggested. However this produces the exact >> same error as before. The preamble to my WSDL now looks like: >> >> >> > targetNamespace="http://www.test.com/TestService/"; >> xmlns:tns="http://www.test.com/TestService/"; >> xmlns:test="http://www.test.com/test"; >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; >> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >> xmlns="http://schemas.xmlsoap.org/wsdl/";> >> >> >> >> > namespace="http://www.test.com/test"/> >> >> >> >> ... >> >> And the error output looks the same as before: >> >> [java] wsdl2java -verbose -client -b bindings.xml -d >> [...path-to-project >> ommitted...]/src/main/java [...path-to-project >> ommitted...]/src/main/test/test.wsdl >> [java] wsdl2java - Apache CXF (incubator) 2.0.4-incubator >> [java] WSDLToJava Error : java.lang.RuntimeException: Fail to create >> wsdl >> definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl >> [java] org.apache.cxf.tools.common.ToolException: >> java.lang.RuntimeException: Fail to create wsdl definition file: >> [...path-to-project ommitted...]/src/main/test/test.wsdl >> [java] at >> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:237) >> [java] at >> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83) >> [java] at >> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:102) >> [java] at >> org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:171) >> [java] Caused by: java.lang.RuntimeException: Fail to create wsdl >> definition file: [...path-to-project ommitted...]/src/main/test/test.wsdl >> [java] at >> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:130) >> [java] at >> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:123) >> [java] at >> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:229) >> [java] ... 3 more >> [java] Caused by: java.lang.RuntimeException: Failed to Resolve >> types.xsd >> [java] at >> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.CustomizedWSDLLocator.getImportInputSource(CustomizedWSDLLocator.java:129) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown >> Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >> [java] at >> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.buildCustomizedDefinition(JAXWSDefinitionBuilder.java:178) >> [java] at >> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.customize(JAXWSDefinitionBuilder.java:125) >> [java] ... 5 more >> [java] Caused by: java.net.URISyntaxException: Illegal character in path >> at >> index 53: file: [...path-to-project ommitted...]/src/main/test/test.wsdl >> [java] at java.net.URI$Parser.fail(URI.java:2816) >> [java] at java.net.URI$Parser.checkChars(URI.java:2989) >> [java] at java.net.URI$Parser.parseHierarchical(URI.java:3073) >> [java] at java.net.URI$Parser.parse(URI.java:3021) >> [java] at java.net.URI.(URI.java:578) >> [java] at >> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.CustomizedWSDLLocator.getImportInputSource(CustomizedWSDLLocator.java:113) >> [ja
Re: WSDL2Java error when using binding customization
Jesse McLaughlin wrote: Hi Jim, No, there's no strange characters in the full path. There are spaces, but that's about as strange as it gets. You can't have spaces in a java.net.URI, they have to be escaped as %20. I'm not sure whose responsibility it is to do this though... Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
Re: JIRA CXF-1456
On Wednesday 05 March 2008, John-M Baker wrote:
> Is there a fix to http://issues.apache.org/jira/browse/CXF-1456 for
> CXF 2.0.4? Or should I ask, when is 2.0.5 going to be released?
I deployed new snapshots monday night of 2.0.5 that have this fixed. Not
100% positive on the release date yet. Hopefully soon.
> Also, on the subject of SSL, this is far too much effort:
>
> HTTPConduit http = (HTTPConduit)cxfClient.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> http.setTlsClientParameters(tlsParams);
>
> Could CXF not automatically handle SSL in 2.0.5? A URL with https
> should not cause CXF to require extra coding!
I 100% agree. The snapshot fixes this as well which was what sparked
some of the contriversy.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: JIRA CXF-1456
Excellent news. Do you have a timeline for 2.0.5?
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
Daniel Kulp <[EMAIL PROTECTED]>
05/03/2008 14:24
Please respond to
cxf-user@incubator.apache.org
To
cxf-user@incubator.apache.org
cc
John-M Baker/ext/[EMAIL PROTECTED]
Subject
Re: JIRA CXF-1456
On Wednesday 05 March 2008, John-M Baker wrote:
> Is there a fix to http://issues.apache.org/jira/browse/CXF-1456 for
> CXF 2.0.4? Or should I ask, when is 2.0.5 going to be released?
I deployed new snapshots monday night of 2.0.5 that have this fixed. Not
100% positive on the release date yet. Hopefully soon.
> Also, on the subject of SSL, this is far too much effort:
>
> HTTPConduit http = (HTTPConduit)cxfClient.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> http.setTlsClientParameters(tlsParams);
>
> Could CXF not automatically handle SSL in 2.0.5? A URL with https
> should not cause CXF to require extra coding!
I 100% agree. The snapshot fixes this as well which was what sparked
some of the contriversy.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional
EU corporate and regulatory disclosures.
Re: JIRA CXF-1456
Sorry, you did qualify the release date question. I'll try to get 2.0.5
tested here within the next 24 hours.
John Baker
--
Web SSO
IT Infrastructure
Deutsche Bank London
URL: http://websso.cto.gt.intranet.db.com
Daniel Kulp <[EMAIL PROTECTED]>
05/03/2008 14:24
To
cxf-user@incubator.apache.org
cc
John-M Baker/ext/[EMAIL PROTECTED]
Subject
Re: JIRA CXF-1456
On Wednesday 05 March 2008, John-M Baker wrote:
> Is there a fix to http://issues.apache.org/jira/browse/CXF-1456 for
> CXF 2.0.4? Or should I ask, when is 2.0.5 going to be released?
I deployed new snapshots monday night of 2.0.5 that have this fixed. Not
100% positive on the release date yet. Hopefully soon.
> Also, on the subject of SSL, this is far too much effort:
>
> HTTPConduit http = (HTTPConduit)cxfClient.getConduit();
> TLSClientParameters tlsParams = new TLSClientParameters();
> tlsParams.setSecureSocketProtocol("SSL");
> http.setTlsClientParameters(tlsParams);
>
> Could CXF not automatically handle SSL in 2.0.5? A URL with https
> should not cause CXF to require extra coding!
I 100% agree. The snapshot fixes this as well which was what sparked
some of the contriversy.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional
EU corporate and regulatory disclosures.
Re: WSDL2Java error when using binding customization
Cool. Thanks Ian. I changed my setup so as to avoid any spaces in the full project path, and everything started working as expected. So I take it this means there is a bug there... ie. you can't have spaces in your project path if you want to use a binding customization such as this (where as normally, leaving out the binding file, spaces pose no issue). Unless there are any objections, or unless a similar bug has already been logged, I'll add this one into JIRA. Cheers, Jesse. ianroberts wrote: > > Jesse McLaughlin wrote: >> Hi Jim, >> >> No, there's no strange characters in the full path. There are spaces, >> but >> that's about as strange as it gets. > > You can't have spaces in a java.net.URI, they have to be escaped as %20. > I'm not sure whose responsibility it is to do this though... > > Ian > > -- > Ian Roberts | Department of Computer Science > [EMAIL PROTECTED] | University of Sheffield, UK > > -- View this message in context: http://www.nabble.com/WSDL2Java-error-when-using-%3Cjaxb%3Aserializable-%3E-binding-customization-tp15786637p15852009.html Sent from the cxf-user mailing list archive at Nabble.com.
Problem with cxf.xml in maven based, IDE independent client
Hello, i encountered some problems with packaging an independent (simple) client. i still do not know exactly what causes the problem but i guess it must be some validation flag in the SAX parser or something similar. so, my problem was, when i created some maven based project in eclipse, wrote the client, i did not encounter any problems. when i tried to package the whole thing and run it somewhere in the shell, i got several exceptions, Caused by: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'beans'. i modified the XSD references in the root element of cxf.xml ( http://svn.apache.org/viewvc/incubator/cxf/trunk/rt/core/src/main/resources/META-INF/cxf/cxf.xml?view=markup ) from: http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:foo="http://cxf.apache.org/configuration/foo"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd";> to: http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:foo="http://cxf.apache.org/configuration/foo"; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd";> which did the trick for me. the same applies for cxf-extension-soap.xml my app is based on the 2.0.4-incubator POMs from the incubator repository. now i dont know if this is a bug or nothing special since i didnt find anyone complaining about a similar problem. who can help me to get my app running relying on the provided poms? thanks, kind regards, ud
RE: HTTPs and CXF
It turns out that that Dans change didn't actually downgrade the attempted connection to http which was my primary outstanding concern. So I'm happy with the new behaviour:-) Cheers, Donal -Original Message- From: Arundel, Donal [mailto:[EMAIL PROTECTED] Sent: 05 March 2008 12:11 To: cxf-user@incubator.apache.org Subject: RE: HTTPs and CXF However for clients that DO have specific security requirements one would also want to be able to enforce the use of SSL in some fashion. For these types of secure apps though : basing the decision purely on the URL which might even have been retrieved dynamically over an insecure connection would be inappropriate. In general this (fairly typical) type of secure application would like to be able to specify this type of strictly secure behaviour at a high level (not per conduit/endpoint). Cheers, Donal IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: CXF & Spring Transactions
I was having an Aspect do some things using a @Before annotation. It seems it was interfering with the flow of things. It turns out this happens with Spring-WS as well, which is how I found out. I simply disabled the aspect and it is working (for the most part). I just have to fix my aspect. David Castañeda wrote: > > Can you explain it? > > how is your configuration now? > > -- > David Castañeda R. > > -- View this message in context: http://www.nabble.com/CXF---Spring-Transactions-tp15814197p15852485.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF & Spring Transactions
Can you explain it? how is your configuration now? On Wed, Mar 5, 2008 at 8:36 AM, Michael McCaskill <[EMAIL PROTECTED]> wrote: > > I have found the root of the problem, which fortunately isn't CXF related > but > a Spring-AOP (AspectJ) problem. Thanks. > -- > View this message in context: > http://www.nabble.com/CXF---Spring-Transactions-tp15814197p15850223.html > Sent from the cxf-user mailing list archive at Nabble.com. > > -- David Castañeda R.
Re: Contract-last, empty List null
Tell us more about what you did and how you configured it. Can you post a JIRA with a test case? On Wed, Mar 5, 2008 at 8:46 AM, Michael McCaskill <[EMAIL PROTECTED]> wrote: > > I've checked the response from my server side web service method. It is > indeed not null and empty. But the client gets a null object back. I tried > using the CXF 2.1-SNAPSHOT (for JAXB 2.1) but I couldn't get my services > to > work. What else can I try short of writing XSDs? > -- > View this message in context: > http://www.nabble.com/Contract-last%2C-empty-List-null-tp15850232p15850232.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
Re: Nordic charaters problem in SOAP/MQ
Could you please send along these characters in hex? I am not confident that we're seeing the same stuff. I suspect that the CXF->MQ connector is failing to tell MQ about UTF-8 somehow, but I need a little more traction. On Wed, Mar 5, 2008 at 7:31 AM, mr.andersen <[EMAIL PROTECTED]> wrote: > > I'm expecting UTF-8 since the reciever expects that I live up to WS-I > Basic > Profile. > And it's also my understanding that CXF uses UTF-8 all the way, but I > cannot > understand why my å is converted to Ã¥ when SOAPMessage.writeTo() is used. > > > Benson Margulies-4 wrote: > > > > In every other area, CXF writes UTF-8. Are you expecting UTF-8, or > > something > > else? > > > > On Wed, Mar 5, 2008 at 4:00 AM, mr.andersen <[EMAIL PROTECTED]> wrote: > > > >> > >> I have at problem with sending nordic charaters such as æøå via SOAP > over > >> MQ. > >> I'm using cxf version 2.0.1 and SAAJ version 1.3. > >> > >> I have tried to trace where is could go wrong and what I can see, the å > >> looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), > >> but > >> when the SOAPMessage.writeTo() method is called with System.out or > >> OutputStream in SAAJOutInterceptor it is viewed as Ã¥. > >> > >> Can anyone tell me if I can do anything to avoid this behaviour or have > >> it > >> something to do with the SAAJ implementation? > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15845741.html > >> Sent from the cxf-user mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15848926.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
Re: Code Fisrt + JSON: xmlbinding problem
Also, definitely take a look at the restful_http_binding sample. That doesn't use a wsdl. Actually, if you can modify that to show the same problem you are seing, that would be fine as well. Dan On Wednesday 05 March 2008, Willem Jiang wrote: > You could fill a jira and attach the test case with it. > Willem > > On 3/5/08, Luca Ceppelli <[EMAIL PROTECTED]> wrote: > > > > Hi all. > > > > > > I'm trying to use CXF as > > backed for a web base application (Flex). Cxf has to expose json > > over http endpoint. The approach should be "code first" instead > > "wsdl first" for speeding up the development process. > > > > > > CXF has some problem with > > this (or maybe I was not able to run it properly), the problem is > > related with the xmlbinding. Did someone have the same experience? > > I have created a test > > case, how I could share it? Do I send it to this mailing list? > > > > > > > > > > Thanks, > > Luca. > > > > > > P.S. The problem happens > > with: > > > > > > 2.0-incubator > > 2.0.4-incubator > > 2.0.4.0-fuse > > 2.1-incubator-SNAPSHOT > > > > > > > > > > > > > > ___ > > L'email della prossima generazione? Puoi averla con la nuova Yahoo! > > Mail: http://it.docs.yahoo.com/nowyoucan.html -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Nordic charaters problem in SOAP/MQ
Can you try just using the SAAJ API's in a quick standalone program to create a soap message then write it out to a file, then read it into a new SAAJ message and see if the problem remains? If so, it's definitely a bug in the SAAJ implemenetation. If not, it MAY be an issue with the JMS transport. Dan On Wednesday 05 March 2008, mr.andersen wrote: > I have at problem with sending nordic charaters such as æøå via SOAP > over MQ. I'm using cxf version 2.0.1 and SAAJ version 1.3. > > I have tried to trace where is could go wrong and what I can see, the > å looks okay when it is added to > W3CDOMXMLStreamWriter.writeCharaters(), but when the > SOAPMessage.writeTo() method is called with System.out or OutputStream > in SAAJOutInterceptor it is viewed as Ã¥. > > Can anyone tell me if I can do anything to avoid this behaviour or > have it something to do with the SAAJ implementation? -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: JSR311 Maven Jars Issue
Forgot to mention -- I'm running JDK 1.5.0. -- View this message in context: http://www.nabble.com/JSR311-Maven-Jars-Issue-tp14670128p15860484.html Sent from the cxf-user mailing list archive at Nabble.com.
NullPointerException after cxfEndpoint.getOutInterceptors().clear()
If I have a CXF client which is set as
(BindingProvider.SESSION_MAINTAIN_PROPERTY, true), I do not want the client
to send the following tag for all subsequent requests after
the first successful request:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soap:mustUnderstand="1">
If I do so by:
cxfEndpoint.getOutInterceptors().clear();
the CXF API gives me an erorr as below:
Mar 5, 2008 4:20:14 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
If I use an SOAP client coded with the Axis2 API, I can do so after the
first successful request with no issue by calling:
client.disengageModule("rampart");
It seems to me that the CXF API should check if the list of OutInterceptors
is empty or not, and would do nothing if it is indeed empty.
--
View this message in context:
http://www.nabble.com/NullPointerException-after-cxfEndpoint.getOutInterceptors%28%29.clear%28%29-tp15861038p15861038.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: NullPointerException after cxfEndpoint.getOutInterceptors().clear()
The issue is that you are probably clearing out a bunch of interceptors
(like all the soap interceptors) that need to be there. Most likely,
the null pointer is not due to it being empty, but due to something else
expecting a particular interceptor to be there.
Before calling clear, can you see which interceptors are there? In
general, only remove the interceptors that you added.
Dan
On Wednesday 05 March 2008, Landslide wrote:
> If I have a CXF client which is set as
> (BindingProvider.SESSION_MAINTAIN_PROPERTY, true), I do not want the
> client to send the following tag for all subsequent
> requests after the first successful request:
>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-ws
>security-secext-1.0.xsd" soap:mustUnderstand="1">
>
>
>
> If I do so by:
> cxfEndpoint.getOutInterceptors().clear();
> the CXF API gives me an erorr as below:
> Mar 5, 2008 4:20:14 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> java.lang.NullPointerException
>
> If I use an SOAP client coded with the Axis2 API, I can do so after
> the first successful request with no issue by calling:
> client.disengageModule("rampart");
>
> It seems to me that the CXF API should check if the list of
> OutInterceptors is empty or not, and would do nothing if it is indeed
> empty.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Accessing WebService that requires username/password
How should a webservice that requires basic username/password for
authentication be accessed? The CXF service class that is autogenerated
extends the javax.xml.ws.Service class. So when the client tries to
instantiate it, it fails because it gets java.io.IOException: Server
returned HTTP response code: 401 for URL.
Looking at the documentation, and on the web, it seems that what is needed
is to add something like this:
//Create a dispatch instance
Dispatch dispatch =
createDispatch(WebService1, SOAPMessage.class,
Service.Mode.MESSAGE);
// Use Dispatch as BindingProvider
BindingProvider bp = (BindingProvider) dispatch;
// Optionally Configure RequestContext to send SOAPAction HTTP
Header
Map rc = bp.getRequestContext();
rc.put(BindingProvider.USERNAME_PROPERTY, userName);
rc.put(BindingProvider.PASSWORD_PROPERTY, password);
before the service hits the url. However, given that service derives from
javax.xml.ws.Service class whose constructor is protected, how do I do that,
given that constructor looks like:
public WebServiceX() {
super(WSDL_LOCATION, SERVICE);
}
and in the super's constructor (javax.xml.ws.Service), the class tries to
connect to the url that needs the username and password, and due to java,
call to super must be the first call in the deriver class's constructor.
Note that this is not an https service, but just an http service that works
well when I invoke it from the browser (once I provide username and password
in the dialog box provided by the browser).
Any help greatly appreciated!
--
View this message in context:
http://www.nabble.com/Accessing-WebService-that-requires-username-password-tp15863184p15863184.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WSDL2Java error when using binding customization
Go ahead, Jesse. Wsdl2java tool will use different class to process customization(binding file), so we need to process the URI contains spaces before it invokes JAXWSDefinitionBuilder class. Cheers Jim Ma On Wed, Mar 5, 2008 at 10:56 PM, Jesse McLaughlin <[EMAIL PROTECTED]> wrote: > > Cool. Thanks Ian. I changed my setup so as to avoid any spaces in the > full > project path, and everything started working as expected. So I take it > this > means there is a bug there... ie. you can't have spaces in your project > path > if you want to use a binding customization such as this (where as > normally, > leaving out the binding file, spaces pose no issue). > > Unless there are any objections, or unless a similar bug has already been > logged, I'll add this one into JIRA. > > Cheers, > Jesse. > > > > ianroberts wrote: > > > > Jesse McLaughlin wrote: > >> Hi Jim, > >> > >> No, there's no strange characters in the full path. There are spaces, > >> but > >> that's about as strange as it gets. > > > > You can't have spaces in a java.net.URI, they have to be escaped as %20. > > I'm not sure whose responsibility it is to do this though... > > > > Ian > > > > -- > > Ian Roberts | Department of Computer Science > > [EMAIL PROTECTED] | University of Sheffield, UK > > > > > > -- > View this message in context: > http://www.nabble.com/WSDL2Java-error-when-using-%3Cjaxb%3Aserializable-%3E-binding-customization-tp15786637p15852009.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
Re: Accessing WebService that requires username/password
Sadly, I was able to get this portion of your code below to work for
Metro but not CXF:
rc.put(BindingProvider.USERNAME_PROPERTY, userName);
rc.put(BindingProvider.PASSWORD_PROPERTY, password);
I have been meaning to look at this to find out the reason why. But in
the meantime, CXF has an alternate method of supplying this information,
documented here[1].
Glen
[1] http://tinyurl.com/ytc77j
Am Mittwoch, den 05.03.2008, 15:37 -0800 schrieb xbranko:
> How should a webservice that requires basic username/password for
> authentication be accessed? The CXF service class that is autogenerated
> extends the javax.xml.ws.Service class. So when the client tries to
> instantiate it, it fails because it gets java.io.IOException: Server
> returned HTTP response code: 401 for URL.
>
> Looking at the documentation, and on the web, it seems that what is needed
> is to add something like this:
>
> //Create a dispatch instance
> Dispatch dispatch =
>createDispatch(WebService1, SOAPMessage.class,
> Service.Mode.MESSAGE);
>
> // Use Dispatch as BindingProvider
> BindingProvider bp = (BindingProvider) dispatch;
>
> // Optionally Configure RequestContext to send SOAPAction HTTP
> Header
> Map rc = bp.getRequestContext();
> rc.put(BindingProvider.USERNAME_PROPERTY, userName);
> rc.put(BindingProvider.PASSWORD_PROPERTY, password);
>
> before the service hits the url. However, given that service derives from
> javax.xml.ws.Service class whose constructor is protected, how do I do that,
> given that constructor looks like:
>
> public WebServiceX() {
> super(WSDL_LOCATION, SERVICE);
> }
>
> and in the super's constructor (javax.xml.ws.Service), the class tries to
> connect to the url that needs the username and password, and due to java,
> call to super must be the first call in the deriver class's constructor.
>
> Note that this is not an https service, but just an http service that works
> well when I invoke it from the browser (once I provide username and password
> in the dialog box provided by the browser).
>
> Any help greatly appreciated!
Re: Stubs and Ports
We have our own java2wsdl tool you can use. Axis2's work I believe is not JAX-WS standard, they do their own thing. Glen Am Dienstag, den 04.03.2008, 16:39 + schrieb John-M Baker: > Hello, > > I appreciate I'm asking a lot of questions today - sorry. I guess I'm > adding lots to the mail archive :) > > When a stub is generated, a number of get methods exist for the various > ports defined in the WSDL. If I call getQuerySOAP11PortHttp() then I can > make a WS call and everything work as expected. If I call getQueryHttpport > then the following stack trace is generated: > > Caused by: org.apache.cxf.BusException: No binding factory for namespace > http://schemas.xmlsoap.org/wsdl/http/ registered. > at > org.apache.cxf.binding.BindingFactoryManagerImpl.getBindingFactory(BindingFactoryManagerImpl.java:82) > at > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:87) > at > org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:51) > ... 7 more > > I appreciate this most probably has something to do with my WSDL, which > was generated by the Axis2 java2wsdl task. But I'd be interested to hear > what is wrong. WSDL at bottom of mail (for completeness). > > Thanks, > > > John > > > http://schemas.xmlsoap.org/wsdl/"; > xmlns:ns4="http://ldap.dao.websso.db.com/xsd"; > xmlns:ns0="http://ldap.springframework.org/xsd"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"; > xmlns:ns5="http://service.ws.websso.db.com"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:ns6="http://dao.websso.db.com/xsd"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:ns1="http://util.java/xsd"; > xmlns:ns3="http://persistent.dao.websso.db.com/xsd"; > xmlns:ns2="http://websso.db.com/xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > targetNamespace="http://service.ws.websso.db.com";> > > http://ldap.springframework.org/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified" > targetNamespace="http://ldap.springframework.org/xsd";> > > > nillable="true" type="ax28:ContextSource"/> > nillable="true" type="ax28:NamingExceptionTranslator"/> > name="ignorePartialResultException" type="xs:boolean"/> > > > > > nillable="true" type="xs:anyType"/> > nillable="true" type="xs:anyType"/> > > > > > > > http://util.java/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified" > targetNamespace="http://util.java/xsd";> > > > type="xs:boolean"/> > > > > > > > > type="xs:boolean"/> > > > > http://websso.db.com/xsd"; > xmlns:ax26="http://util.java/xsd"; attributeFormDefault="qualified" > elementFormDefault="qualified" targetNamespace="http://websso.db.com/xsd";> > http://util.java/xsd"/> > > > nillable="true" type="ax26:Map"/> > nillable="true" type="xs:string"/> > nillable="true" type="xs:string"/> > type="xs:boolean"/> > type="xs:int"/> > nillable="true" type="xs:string"/> > name="scheduledReportDirectory" nillable="true" type="xs:string"/> > > > > http://util.java/xsd"; > xmlns:ax21="http://persistent.dao.websso.db.com/xsd"; > attributeFormDefault="qualified" elementFormDefault="qualified" > targetNamespace="http://persistent.dao.websso.db.com/xsd";> > http://util.java/xsd"/> > > > nillable="true" type="ns3:Application"/> > nillable="true" type="ns3:EventInformation"/> > nillable="true" type="ns3:EventSource"/> > > > nillable="true" type="xs:dateTime"/> > type="ns3:User"/> > > > > > > > > > > > > type="xs:int"/> > name="eventSummaries" nillable="true" type="ax23:Set"/> > name="eventSummariesIterator" nillable="true" type="ax23:Iterator"/> >
Re: Accessing WebService that requires username/password
Does the WSDL_LOCATION also point to the server which you need to access?
If so , here is my explain of this issue.
In CXF we just use WSDL4J and use a common URL class to load the wsdl,
so what you set on the client side will not affect the WSDL4J's URL.
CXF will build a service model with the WSDL before you client hit the
server , so you got that error.
Willem
Glen Mazza wrote:
Sadly, I was able to get this portion of your code below to work for
Metro but not CXF:
rc.put(BindingProvider.USERNAME_PROPERTY, userName);
rc.put(BindingProvider.PASSWORD_PROPERTY, password);
I have been meaning to look at this to find out the reason why. But in
the meantime, CXF has an alternate method of supplying this information,
documented here[1].
Glen
[1] http://tinyurl.com/ytc77j
Am Mittwoch, den 05.03.2008, 15:37 -0800 schrieb xbranko:
How should a webservice that requires basic username/password for
authentication be accessed? The CXF service class that is autogenerated
extends the javax.xml.ws.Service class. So when the client tries to
instantiate it, it fails because it gets java.io.IOException: Server
returned HTTP response code: 401 for URL.
Looking at the documentation, and on the web, it seems that what is needed
is to add something like this:
//Create a dispatch instance
Dispatch dispatch =
createDispatch(WebService1, SOAPMessage.class,
Service.Mode.MESSAGE);
// Use Dispatch as BindingProvider
BindingProvider bp = (BindingProvider) dispatch;
// Optionally Configure RequestContext to send SOAPAction HTTP
Header
Map rc = bp.getRequestContext();
rc.put(BindingProvider.USERNAME_PROPERTY, userName);
rc.put(BindingProvider.PASSWORD_PROPERTY, password);
before the service hits the url. However, given that service derives from
javax.xml.ws.Service class whose constructor is protected, how do I do that,
given that constructor looks like:
public WebServiceX() {
super(WSDL_LOCATION, SERVICE);
}
and in the super's constructor (javax.xml.ws.Service), the class tries to
connect to the url that needs the username and password, and due to java,
call to super must be the first call in the deriver class's constructor.
Note that this is not an https service, but just an http service that works
well when I invoke it from the browser (once I provide username and password
in the dialog box provided by the browser).
Any help greatly appreciated!
RE: Accessing WebService that requires username/password
I am using something like this:
FoobarService foobarService = new FoobarService();
FoobarPortType foobarPort = foobarService.getFoobarPort();
context = ((BindingProvider) foobarPort).getRequestContext();
context.put(USERNAME, "me");
context.put(PASSWORD, "hello");
context.put(ENDPOINT_ADDRESS, "http://localhost/ws/services/Foobar";);
FoobarService and FoobarPortType are generated by wsdl2java
and I include those classes in a JAR that is available on
both the client side and server side.
- Dan
> -Original Message-
> From: xbranko [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 05, 2008 4:38 PM
> To: cxf-user@incubator.apache.org
> Subject: Accessing WebService that requires username/password
>
>
> How should a webservice that requires basic username/password for
> authentication be accessed? The CXF service class that is
> autogenerated
> extends the javax.xml.ws.Service class. So when the client tries to
> instantiate it, it fails because it gets java.io.IOException: Server
> returned HTTP response code: 401 for URL.
>
> Looking at the documentation, and on the web, it seems that
> what is needed
> is to add something like this:
>
> //Create a dispatch instance
> Dispatch dispatch =
>createDispatch(WebService1, SOAPMessage.class,
> Service.Mode.MESSAGE);
>
> // Use Dispatch as BindingProvider
> BindingProvider bp = (BindingProvider) dispatch;
>
> // Optionally Configure RequestContext to send SOAPAction HTTP
> Header
> Map rc = bp.getRequestContext();
> rc.put(BindingProvider.USERNAME_PROPERTY, userName);
> rc.put(BindingProvider.PASSWORD_PROPERTY, password);
>
> before the service hits the url. However, given that service
> derives from
> javax.xml.ws.Service class whose constructor is protected,
> how do I do that,
> given that constructor looks like:
>
> public WebServiceX() {
> super(WSDL_LOCATION, SERVICE);
> }
>
> and in the super's constructor (javax.xml.ws.Service), the
> class tries to
> connect to the url that needs the username and password, and
> due to java,
> call to super must be the first call in the deriver class's
> constructor.
>
> Note that this is not an https service, but just an http
> service that works
> well when I invoke it from the browser (once I provide
> username and password
> in the dialog box provided by the browser).
>
> Any help greatly appreciated!
> --
> View this message in context:
> http://www.nabble.com/Accessing-WebService-that-requires-usern
> ame-password-tp15863184p15863184.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: Nordic charaters problem in SOAP/MQ
Hmm - maybe I should look have the MQ is setup - but I don't think the problems has come so far yet, since the å (0xC3 0xA5) is wrong before the message is put on a queue. Benson Margulies-4 wrote: > > Could you please send along these characters in hex? I am not confident > that > we're seeing the same stuff. > > I suspect that the CXF->MQ connector is failing to tell MQ about UTF-8 > somehow, but I need a little more traction. > > On Wed, Mar 5, 2008 at 7:31 AM, mr.andersen <[EMAIL PROTECTED]> wrote: > >> >> I'm expecting UTF-8 since the reciever expects that I live up to WS-I >> Basic >> Profile. >> And it's also my understanding that CXF uses UTF-8 all the way, but I >> cannot >> understand why my å is converted to Ã¥ when SOAPMessage.writeTo() is >> used. >> >> >> Benson Margulies-4 wrote: >> > >> > In every other area, CXF writes UTF-8. Are you expecting UTF-8, or >> > something >> > else? >> > >> > On Wed, Mar 5, 2008 at 4:00 AM, mr.andersen <[EMAIL PROTECTED]> wrote: >> > >> >> >> >> I have at problem with sending nordic charaters such as æøå via SOAP >> over >> >> MQ. >> >> I'm using cxf version 2.0.1 and SAAJ version 1.3. >> >> >> >> I have tried to trace where is could go wrong and what I can see, the >> å >> >> looks okay when it is added to W3CDOMXMLStreamWriter.writeCharaters(), >> >> but >> >> when the SOAPMessage.writeTo() method is called with System.out or >> >> OutputStream in SAAJOutInterceptor it is viewed as Ã¥. >> >> >> >> Can anyone tell me if I can do anything to avoid this behaviour or >> have >> >> it >> >> something to do with the SAAJ implementation? >> >> >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15845741.html >> >> Sent from the cxf-user mailing list archive at Nabble.com. >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15848926.html >> Sent from the cxf-user mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Nordic-charaters-problem-in-SOAP-MQ-tp15845741p15867235.html Sent from the cxf-user mailing list archive at Nabble.com.
