I'm sorry, I'm failing to be very helpful. This will have to wait for
someone with more understanding of this area to turn up.
On Wed, Dec 30, 2009 at 8:53 PM, conficio wrote:
>
>
> bimargulies wrote:
>>
>> 2.0.12 so old that all bets are off.
>>
> Well, as the relevant code has not changed up to
bimargulies wrote:
>
> 2.0.12 so old that all bets are off.
>
Well, as the relevant code has not changed up to 2.2.4, I'd be happy to know
the solution for any newer version.
I have tested that
log4j.category.org.apache.cxf=ERROR
does suppress the stack trace. But I don't know why I need to
> -Original Message-
> From: Gary Gregory
> Sent: Sunday, December 27, 2009 16:16
> To: 'Daniel Kulp'; users@cxf.apache.org
> Subject: RE: Inflexible fault interceptor chain?
>
> > -Original Message-
> > From: Daniel Kulp [mailto:dk...@apache.org]
> > Sent: Tuesday, December 22, 200
This is about the code, not the WSDL.
You are making a call to a JAX-WS standard API. That API is provided
in Java 1.6. If you want to use CXF's version, instead, you have you
to make sure that you are calling CXF's version.
http://cxf.apache.org/21-migration-guide.html might be relevant, or
not,
I don't think I am following you. I'm fairly new to using Java for web
services in general so if you could be a bit more detailed I would
appreciate it. I created a client (wsdl2java -client) from the wsdl and I am
using that to access the service. As far as I understand it, the location of
the ws
No, that it is a problem with your classpath. If you're trying to use
CXF to launch this endpoint, you've ended up with the Java 1.6 or
Glassfish / Metro versions instead.
javax.xml.ws.Service at the bottom of your stack is the symptom, I think.
On Wed, Dec 30, 2009 at 3:05 PM, caseyd418 wrote:
So are you saying that this is a problem with Glassfish? I suppose I can get
tomcat up and running locally and try it there.
bimargulies wrote:
>
> That's not a CXF stack trace! That's the Sun reference implementation at
> work.
>
> On Wed, Dec 30, 2009 at 2:11 PM, caseyd418 wrote:
>>
>> I ha
That's not a CXF stack trace! That's the Sun reference implementation at work.
On Wed, Dec 30, 2009 at 2:11 PM, caseyd418 wrote:
>
> I have a web start app that is all packaged and signed as a single jar (with
> a couple of dependent jars). This is all being deployed as a WAR to a
> Glassfish ser
I have a web start app that is all packaged and signed as a single jar (with
a couple of dependent jars). This is all being deployed as a WAR to a
Glassfish server for right now. Eventually will be deployed to a tomcat
server.
I have generated a CXF client using wsdl2java (CXF version 2.2.5) spe
Dan, I've logged the problem and did some investigation. Logged it as:
https://issues.apache.org/jira/browse/CXF-2599
Thanks,
Craig.
On Fri, Dec 4, 2009 at 10:51 AM, Daniel Kulp wrote:
> On Thu November 19 2009 12:53:33 am Craig Tataryn wrote:
> > Problem we've faced with the catalog solution
Is there a way to have CXF generate the MAP on the outgoing
response message? It seems to only generate To, Action, MessageID and
RelatesTo elements. The client requires the the From element also be
populated, but I haven't been able to find a way to have it included.
element is NOT anonymous
Does anyone know the approximate date that XFire was deprecated in favor
of CXF? For instance, do you know when the notice went up on the XFire
web site about it?
I upgraded to 2.2.5 and see that it is no longer forking. This is perfect.
I'm looking to configure the retry functionality now. It looks like I have
everything configured, but it is not re-trying. It turns out that the
exceptions are captured and converted to faults that would normally go on
the
Perfect. I am using version 2.2.2. It looks like 2.2.5 is the latest version.
I will upgrade and see what the impact on our application is. How is the
flag configured? Or does the JMS handler automatically set forking to false?
dkulp wrote:
>
>
> What version of CXF?
>
> The latest versions o
Thanks for your feedback. Unfortunately, I have a requirement to make the
endpoint one-way synchronous. I actually go through an ESB and I want the
client call to the ESB to be asynchronous. By having the endpoint be
synchronous, I can take advantage of the re-try functionality. Going
asynchronous
Sure, this is what JAXRSOutInterceptor does :
MessageContentsList objs = MessageContentsList.getContentsList(message);
if (objs == null || objs.size() == 0) {
return;
}
if (objs.get(0) != null) {
// this is what a given JAXRS method has returned : JAXRS Response,
Book, Feed, etc
Cool - thanks
Is it possible to get hold of the JAXRS Response object in an impl of a
AbstractOutDatabindingInterceptor
In order to generate an etag from the response entity (not the http
response object, but the JAXRS Response) ?
-Original Message-
From: Sergey Beryozkin [mailto:sbery..
Hi
Some more updates have been applied to the WADLGenerator recently :
- if a parent path has a trailing slash and a subresource path has a
leading slash (at a JAXRS code level) then this leading slash will not
be visible in WADL which will help some tools to concatenate multiple
paths
- improve
Hi
Sorry about it, I fixed it, should be Message.PROTOCOL_HEADERS
Cheers, Sergey
-Original Message-
From: Paul Wilton [mailto:paul.wil...@bbc.com]
Sent: 30 December 2009 10:39
To: users@cxf.apache.org
Subject: Message.RESPONSE_HEADERS does not exist as documented in CCXF
2.2.5
Hi
In
Hi
In the documentation here is describes how to add a custom out
databinding interceptor to modify the response headers (eg to add an
ETag):
http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-Overridingresponsest
atuscodeandheaders
However the String Message.RESPONSE_HEADERS does not exist
You are fantastically helpful! We are just about to seriously hit the custom
transport, so this will help!
Thanks!
--- On Mon, 12/21/09, Daniel Kulp wrote:
> From: Daniel Kulp
> Subject: Re: Async Invocation & Custom Transport
> To: users@cxf.apache.org
> Cc: "Coder One"
> Date: Monday, Dec
21 matches
Mail list logo
