Thanks for pointing me in the right direction, Ian. I also suspected
that it's an encoding problem but I wasn't sure.
Unfortunately, after some more trialerror tests, I didn't come to a
positive result. Removing the @SOAPBinding i.e. using wrapped
document/literal/wrapped generates a far more
Hi
jsr-311 api 0.6 introduces a SecurityContext[1] to be available to a user code.
Using Acegi (provided Acegi is enhanced a bit) as originally suggested by Donal
seems like a more scalable solution in terms of the code maintenance.
Cheers, Sergey
[1]
Hi
This update is in place now, so if you're using CXF JAX-RS then please give it
a try.
Please note that a newer 0.6 version is already available, and from the user's
perspective,
upgrading to 0.6 will mean that existing @UriParam annotations will need to be
replaced with
@PathParam ones. It
Should be the latest one:2.0.4
Thanks for the reply.
On 2/23/08 11:49 AM, Benson Margulies [EMAIL PROTECTED] wrote:
What version of CXF have you got?
On Fri, Feb 22, 2008 at 4:39 PM, Li, Weiye [EMAIL PROTECTED] wrote:
The CXF document says that Aegis data binding can even works on Map. I
Please try my suggestion of declaring MapType,Type in your SEI instead of
just 'map'.
On Mon, Feb 25, 2008 at 10:04 AM, Li, Weiye [EMAIL PROTECTED] wrote:
Should be the latest one:2.0.4
Thanks for the reply.
On 2/23/08 11:49 AM, Benson Margulies [EMAIL PROTECTED] wrote:
What version of
I think I may have to declare .aegis.xml.
It was my 2nd try (I mean, use Map only). I did use MapInteger, Employee on
my first try and the outcome is the same: empty map returned.
On 2/24/08 12:09 PM, Benson Margulies [EMAIL PROTECTED] wrote:
It does work. But you have to tell it what's in the
Dan,
I've tried out the 2.1 snapshot available today and found that the API has
changed in some way in CXF so now trying to generate a WSDL from Java code
gives:
Exception in thread main java.lang.NoSuchMethodError:
My testing Jax-WS with Aegis worked only with RPC style. When I changed
soapbinding with RPC style, the same codes give exception. Here's my WS file:
@WebService(name=EmicroManager, targetNamespace=http://emicro.test;)
@SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL,
Sergey Beryozkin wrote:
Hi
This update is in place now, so if you're using CXF JAX-RS then please give it
a try.
Please note that a newer 0.6 version is already available, and from the user's
perspective,
upgrading to 0.6 will mean that existing @UriParam annotations will need to be
Just to be clear:
I do have a question. 0.6 started implementing a REST client API.
Does CXF plan to use this Client API or do you suggesting using the
HTTP Client used in samples?
If it's part of the spec, then yes, we do plan on providing it, just
probably not immediately. The server
If you get rid of all your JAX-WS annotations except @WebParam, which are
not needed for CXF, you won't get this error. I tried it with your test
case.
On Mon, Feb 25, 2008 at 10:35 AM, Li, Weiye [EMAIL PROTECTED] wrote:
My testing Jax-WS with Aegis worked only with RPC style. When I changed
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string
SOAP-ENV:stringArray
Client API It's not part of the spec (at the moment). It's something Jersey
will provide
Cheers, Sergey
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Sent: Monday, February 25, 2008 4:26 PM
Subject: Re: JAX-RS API version change
Just to
On Monday 25 February 2008, Benson Margulies wrote:
The use of HashMap as a JAX-WS wrapper type may be a problem. Let me
try the Mapx,y experiment in my testbed.
Uhh yea. In general, unless you REALLY know what you are doing,
for code first, don't put @RequestWrapper and
Client API It's not part of the spec (at the moment). It's something
Jersey will provide
Oh. Ok.
Well, my comment still stands. Any help adding it to CXF would be
greatly appreciated. :-)
Dan
On Monday 25 February 2008, Sergey Beryozkin wrote:
Cheers, Sergey
- Original
Well, my comment still stands. Any help adding it to CXF would be
greatly appreciated. :-)
+1 :-)
Cheers, Sergey
Client API It's not part of the spec (at the moment). It's something
Jersey will provide
Oh. Ok.
Well, my comment still stands. Any help adding it to CXF would be
On Saturday 23 February 2008, Benson Margulies wrote:
2.0.4 doesn't know anything about xmime:expectedContentType, AFAIK. Do
you have the @MTOM annotation in place to enable the threshold?
Yea, you're backwords
2.0.4 should deal with the expectedContentType stuff fine. It DOESN'T,
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK
I reported the same issue in 2.0.3 a while back, and I did have my Map
specified as MapString, String. (It was a service that had previously
worked under XFire.)
I got no response, so I switched to JAXB and just wrapped the Map inside
a bean.
-Original Message-
From: Benson Margulies
I have got some WebServices that basically take and return
MapString,String and ListString. I am wondering what is
considered the best way to do this, especially for interoperability
with both Java and .NET. I don't have to use the Java collections
(although it sure is convenient). Previously
Maps are hard. JAXB barely support them, with a ton of snails, in 2.1. I
would personally recommend specifying a vector or list of pairs instead.
On Mon, Feb 25, 2008 at 6:24 PM, Daniel Lipofsky
[EMAIL PROTECTED] wrote:
I have got some WebServices that basically take and return
21 matches
Mail list logo
