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
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:
?xml version=1.0 encoding=utf-8?
definitions
targetNamespace=http://www.test.com/TestService/;
xmlns:tns=http://www.test.com/TestService/;
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
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
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
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
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 æøå
You could fill a jira and attach the test case with it.
Willem
On 3/5/08, Luca Ceppelli [EMAIL PROTECTED] wrote:
!--
@page { size: 21cm 29.7cm; margin: 2cm }
P { margin-bottom: 0.21cm }
--
Hi all.
I'm trying to
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
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
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
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:
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
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);
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
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
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
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
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.
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
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
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
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
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
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,
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
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.
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:
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
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
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
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
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.
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 soap:Header tag for all subsequent requests after
the first successful request:
soap:Header
wsse:Security
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
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
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.
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,
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
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
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);
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
42 matches
Mail list logo
