Hi,
I am trying to get the websphere 9 container's built in security engine to
programmatically generate a soap JAX-WS secure client request to a CXF web
service.
The problem is that websphere's engine is not repeating the EncryptedKey
under each EncryptedData element and is using a
Hi
On 16/10/17 12:35, Eyal Weingart wrote:
Hi,
Not sure to whom i need to send my Questions so hopefully one of you can help
me.
Forwarding to the CXF users list
I want to use the maven plugin cxf-java2wadl-plugin in order to generate WADL
from Java rest APIs in build time but i found
Right, this exception is not seen at all by web browsers... The client received
a corrupted ZIP archive. No error is pop-up :-/
That's why I'm wondering if there is any ways to indicate this case, though
protocols.
-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Hi Anthony
And in the browser case this exception is not recognized/seen at all ?
What I'm trying to say, is that if, in the Java client case, it is
recognized then then browser should also be well capable of reporting
the error, and thus preventing the user downloading a corrupted Zip file
Hi Sergey,
The server throws an exception when there is an issue during the ZIP generation.
Anthony
-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: lundi 16 octobre 2017 11:15
To: users@cxf.apache.org
Subject: Re: JAX-RS Interrupt StreamingOutput
Hi,
Hi,
How does the JAX-RS server code react when it sees some issue, does it
throw some exception ?
Sergey
On 16/10/17 10:05, MULLER, Anthony wrote:
Hi Sergey,
Thank you very much for your reply!
The point here is that the client isn't a Java application, but a Web browser
for instance
Hi Sergey,
Thank you very much for your reply!
The point here is that the client isn't a Java application, but a Web browser
for instance (like Chrome).
Best regards,
Anthony
-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: lundi 16 octobre 2017 10:38
To:
Hi Anthony
AFAIK the status goes first with the 1st write, so there's really no way
to replace it with something else if there was an error later on while
writing the stream.
I don't think so the fact a client gets 200 and then, presumably,
IOException, is inconsistent, the client code
