You can give this a try, but a caveat in that I've never tried this so I don't
know what the resulting soap message looks like:
If you set a property on the endpoint like:
the the SOAP out interceptors will stick a stack trace into the fault. Not
exactly sure what that ends up looking
That response message was from running a test using the CXF stack. The
message below is from the Sun stack running the same test. We need to do
some post-processing on service exception and need to know the root cause of
that exception.
Thanks,
Kiffin
http://schemas.xmlsoap.org/soap/envelope/";
Per spec, the "faultstring" should be the result of exception.getMessage().
Thus, we output whatever that returns. Is there any way you can look at the
sun generated exceptions or something to see if they are doing something funky
with the getMessage() call?
Is the sample below from th
I have another question on soap fault. I could see the root cause returning
from the soap fault from my Sun JAX-WS service, but I am not seeing it in
the CXF implementation. Is there a way for CXF to return the root cause of
the soap fault to a client? Here's the example response from my test.
Patch applied.Tomorrows snapshots should have it.
Dan
On Fri February 12 2010 11:05:25 am Michel Decima wrote:
> Hi Dan,
>
> dkulp wrote:
> > I'd be ok changing the default if it would be more interopable.
> >
> > Please file a JIRA with a patch. :-)
>
> Here it is:
>
> JIRA CXF-2669 -
On Fri February 12 2010 3:06:52 pm kiffin wrote:
> Hi. I am porting a Sun JAX-WS service to CXF. Sun has a system property -
> com.sun.xml.ws.transport.http.client.HttpTransportPipe.dum - which dumps
> the request/response message on the console. Does CXF have an equivalent
> property to dump the r
Hi. I am porting a Sun JAX-WS service to CXF. Sun has a system property -
com.sun.xml.ws.transport.http.client.HttpTransportPipe.dum - which dumps the
request/response message on the console. Does CXF have an equivalent
property to dump the request/response message on the console?
--
View this
Many thanks for your help.
Eoghan Glynn-4 wrote:
>
> Hi Charles,
>
> Here's the schema type used by CXF for the CreateSequence message:
>
>
>
>
>
>
>maxOccurs="unbounded">
>
>
> It is the authors intent that this extensibility be used t
Hi Charles,
Here's the schema type used by CXF for the CreateSequence message:
It is the authors intent that this extensibility be used to transfer a
Security Token Reference as defined in WS-Security.
Note the absence
Here is the info. SOAPUI sends the tag without any data.
18:08:01,296 | INFO | 5457...@qtp1-0 | LoggingInInterceptor |
interceptor.LoggingInInterceptor 160 | Inbound Message
ID: 1
Address: /cxf/camel-example/incident
Encoding: ISO-8859-1
Content-Type:
Hi Charles,
Can you capture the payload that SoapUI is sending?
Cheers,
Eoghan
On 12 February 2010 17:11, cmoulliard wrote:
>
> Hi Eoghan,
>
> Yes, the client SOAPUi allows to do that. I have a new error now :
>
> Console of the client
> Fri Feb 12 18:07:57 CET 2010:INFO:StartSequence Request
Hi Eoghan,
Yes, the client SOAPUi allows to do that. I have a new error now :
Console of the client
Fri Feb 12 18:07:57 CET 2010:INFO:StartSequence Request Sent:
2e7dfecf-f888-45c6-8c21-5a10038ea9bc
Fri Feb 12 18:08:02 CET 2010:INFO:Sequence response Received, sequence ID:
on karaf
18:08:02
Hi Dan,
dkulp wrote:
>
> I'd be ok changing the default if it would be more interopable.
>
> Please file a JIRA with a patch. :-)
>
Here it is:
JIRA CXF-2669 - MTOM producer - different content-id in XOP:Include and MIME
part for the same attachment
https://issues.apache.org/jira/browse/CX
Hi All,
The problem has been resolved.
The problem is with "xalan-2.7.1.jar".I have removed this jar file from the
shared library and it works in both tomcat and WAS 6.1.
Regards
Saravanan Ramamoorthy
SaravananRamamoorthy wrote:
>
> Hi All,
>
> I have created cxf webservice client applica
On Fri February 12 2010 5:18:20 am Glen Mazza wrote:
> Hmm, I'm not sure at this late date if anyone wanted to burden the CXF
> project with that old JAX-RPC stuff they would indeed get "support and
> encouragement".
Well, I disagree. If someone would find it useful (and there are enough
lega
Actually, forgot to mention one more (simpler) option to do with the timely
cleanup of the thread-local storage :
try {
webClient.path("bar")
webClient.header("bar", baz);
webClient.invoke(...);
} finally {
// if proxy : WebClient.client(proxy).reset();
webClient.reset();
}
Hi
I've
Hi
It has been fixed :
http://svn.apache.org/viewvc?rev=909411&view=rev
I think many users do explicitly configure providers and if not then they do not see a continious growth (perhaps due to the same
threads coming in back) so noone has reported it yet...CC-ing to the users list so that user
Hi Charles,
The CloseSequence protocol is new in WS-RM 1.1 (
http://docs.oasis-open.org/ws-rx/wsrm/200702)
CXF currently supports WS-RM 1.0 (http://schemas.xmlsoap.org/ws/2005/02/rm).
Hence the non-recognition of the CloseSequence message.
Is your client/message originator using WS-RM 1.1? Can
Hi
I've done some work and now there're few more options to do with making webcliens and proxies thread-safe. I'll chat about proxies a
bit too (it's offtopic for this thread but I'll just try to put all the info in one email, sorry about it)
WebClient.fromClient() will work in all the cases f
Hi,
I have configured CXF 2.2.5 with Apache Camel to process Web Services using
the spec WS-RM. I receive this message in the log of the application server
(Apache Felix Karaf) :
ID: 5
Address: /cxf/camel-example/incident
Encoding: ISO-8859-1
Content-Type: text/xml
Headers: {content-type=[text/x
Well, we certainly supported and encouraged Dain when he did a good dea of it.
On Fri, Feb 12, 2010 at 5:18 AM, Glen Mazza wrote:
>
> Hmm, I'm not sure at this late date if anyone wanted to burden the CXF
> project with that old JAX-RPC stuff they would indeed get "support and
> encouragement".
Hmm, I'm not sure at this late date if anyone wanted to burden the CXF
project with that old JAX-RPC stuff they would indeed get "support and
encouragement". Who would want to maintain and support that? Unless there
is a paid need from one of CXF's sponsors for such functionality, there are
lega
22 matches
Mail list logo
