When that interceptor runs, that just prints something like:
name : userName
Right?
Basically, you'll need to get the object out of the Header object. It's most
likely a DOM so you'll need to get the text content from that dom.
Dan
On Monday 20 September 2010 11:33:22 am willoi wrote:
> Hi
Hi Sergey,
I somehow figured that JAXB bindings are missing in my CustomRequest object but
now I am ending up in following issue. It is not able to create a instance of
InputStream. I chose wild card type, so that everything will be accepted? Will
that cause any issue?
Encoding: ISO-8859-1
Con
Hi,
i am using CXF 2.2.10 with JAXWS/JAXB binding and when an exception is
thrown in a method of @WebService annotated class,
the exception is not serialized in the SOAP:Fault detail (even if it's
annotated with JAXB annotations) .
I searched on the internet and i have seen that it's a known issu
Hi Sergey,
Thanks for a prompt response. I tried using that but I am seeing this exception
now:
Sep 22, 2010 1:08:10 PM org.apache.cxf.jaxrs.client.AbstractClient
reportNoMessageHandler
SEVERE: .No message body writer found for class : class
com.custom.PDFUploadRequest.
Sep 22, 2010 1:08:10 PM
Perhaps I should have been more clear, you *don't* need a self-signed
keystore, and they offer less protection, not more, than CA-signed
certificates.
Your question is not one that should be informally asked & answered on a
mailing list. You need to do some googling and study up on certificates
Yes - if it's a singleton then a thread-safe proxy is injected
cheers, Sergey
On Wed, Sep 22, 2010 at 9:29 PM, Puro, Jeff (HBO-NS) wrote:
> Isn't there an issue of thread safety here? When I initially set up my
> provider it's just a singleton in my spring config. Is there something
> going on
Hi
PDFUploadRequest has to be a JAXB bean, but besides it is probably that
you're using an older version of CXF ?
CXF 2.2.8 should have it working. One more thing to check is whether
InputStream/Filer are supported by JAXB, not quite sure, may be it is only
byte[] and DataHandler.
Oh yes, you need
Isn't there an issue of thread safety here? When I initially set up my
provider it's just a singleton in my spring config. Is there something going
on behind the scenes that makes each provider call thread safe?
Thanks,
Jeff
-Original Message-
From: Sergey Beryozkin [mailto:sberyoz..
Hi
On Wed, Sep 22, 2010 at 8:22 PM, Puro, Jeff (HBO-NS) wrote:
> I am attempting to create a Provider that implements the MessageBodyWriter
> interface. I would like my provider to use XStream to convert the passed in
> object to XML and then perform an XSLT transformation on the xml before
> wr
I am attempting to create a Provider that implements the MessageBodyWriter
interface. I would like my provider to use XStream to convert the passed in
object to XML and then perform an XSLT transformation on the xml before writing
the results to the OutputStream. This is easy enough to do, but
please tell me why do we need a self signed keystore , it works without self
signing , please tell me what is purpose of self signing
--
View this message in context:
http://cxf.547215.n5.nabble.com/cxf-security-tp2848487p2850172.html
Sent from the cxf-user mailing list archive at Nabble.com.
Hi Jeff,
that is interesting. Do you have any idea why this is happening? If it
is a common problem with jndi connectionfactories we could
document it in the wiki.
Would you mind posting your working config. I will try to make some
documentation or an example from it.
Best regards
Christi
Hi
On Wed, Sep 22, 2010 at 3:29 PM, Kampf, Eric wrote:
> Hello.
>
> I am working on an OSGI web application that uses CXF. We have a number of
> existing service classes exposed via SOAP. We would now like to expose
> REST versions of these services. When I built the first REST service, I
>
I may be wrong but I suspect you're mistaking HTTP headers with SOAP headers,
you want the latter.
The file "ReadSOAPHeaderInInterceptor.java" here[1] has an example of
reading SOAP header elements.
HTH,
Glen
[1] http://www.jroller.com/gmazza/entry/jaxwshandlers_to_cxfinterceptors
willoi wrot
I don't know REST much but I would think the JAX-RS XML structure would
follow the JAX-RS specification, just as the SOAP structure follows the
JAX-WS specification, and that the two XML structures would indeed be
different between the two specifications. It would probably be best to code
your RE
I have not done #2, but I think you just need to break out the problem
step-by-step:
1.) hardcode *any* XML/JSON notification to a hardcoded HTTP endpoint.
2.) write web service to collect the HTTP endpoints, and send hardcoded
notification to those endpoints. (Your Step #1 below)
3.) add the busi
I'm assuming you're keeping your keystores *out* of the web application and
in a secure folder in the server, and that your webapp refers to that
keystore on the server. If that's the case, you have the option of just
replacing the keystore but keeping the same name for it in the server
folder, o
A self-signed certificate is a locally created certificate[1] that has not
been vouched for by a third party certificate authority like VeriSign. For
production use you should not be relying on them, but they are OK for
development purposes.
Glen
[1] http://www.jroller.com/gmazza/entry/using_op
Thanks for the help on this. The missing piece to get CXF to work with
MQ configured as a JNDI resource in WebSphere was :
Without this settings, connections are dropped as soon as they're established.
-Jeff
On Wed, Sep 15, 2010 at 2:54 AM, Christian Schneider
wrote:
> Hi Jef
Hello.
I am working on an OSGI web application that uses CXF. We have a number of
existing service classes exposed via SOAP. We would now like to expose REST
versions of these services. When I built the first REST service, I was
surprised to see that the XML it produced did not match the X
Ok, David, I`ll see the source code. Thank you, very much!
cheers,
Fabio
On Wed, Sep 22, 2010 at 4:37 AM, David Bosschaert
wrote:
> Hi Fabio,
>
> The extensibility of the intents implementation in CXF-DOSGi is
> currently probably a little limited. Maybe you would like to look in
> the source c
Hi Fabio,
The extensibility of the intents implementation in CXF-DOSGi is
currently probably a little limited. Maybe you would like to look in
the source code and see if you can come up with an improvement that
would make it more extensible?
Cheers,
David
On 21 September 2010 22:33, Fabio souza
22 matches
Mail list logo
