We have a Web Service client generated with CXF from a WSDL.
We now need to have an access to the generated SOAP requests in order to persist them.
It seems that the framework does not provide this behaviour by default.
Anyway do you guys ever tried to do such a thing?
I am thinking of building my own interceptor that can access to the fully generated message but maybe there is a better choice?
Any advice?
Thanks in advance.
By default CXF uses stax to stream your requests. If you add an interceptor, you can get access to the stax output writer and copy the events.
There is existing code in CXF to force the existence of a DOM tree; see code related to SAAJ and security.
In general, detailed CXF questions get better answers on the CXF user mailing list than here.
Related
I was looking up online how to create a Camel's CXF producer (i.e. create a CXF endpoint that would produce a request to some local/remote web service). Generally, all the examples I could find would list the following steps:
First define the cxfEndpoint attributes:
<cxf:cxfEndpoint
id="orderEndpoint"
address="http://localhost:9000/order/"
serviceClass="camelinaction.order.OrderEndpoint"/>
Then send the request to that endpoint:
...to("cxf:bean:orderEndpoint");
Hmmm. I don't understand the concept. If this is a remote web service, all I usually have is the URL of the WSDL. I can get from it the address of the service... but I don't know what the serviceClass is and I don't have it on my classpath.
So how do I define that cxfEndpoint in case I only have the URL of the WSDL?
Or is there another type of endpoint I should use in that case?
I would suggest looking into WSDL first for cxf. Below are two links that I think should help you out quite a lot and has helped me in the past as well.
http://code.notsoclever.cc/camel-cxf-component-wsdl-first-example/
https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.0/html-single/Web_Services_and_Routing_with_Camel_CXF/index.html#ImplWs-WsdlFirst
On the Red Hat site you will need to start at chapter 3.
Hope this helps.
new to Saml2, I want to use the Kentor AuthServices .net library for generating a Saml2 response, I have checked the output xml and I can't find any node for either "AttributeStatement" or "AuthnStatement".
Does anyone knows how can I deal with them on the library?
Cheers
H
The support in the Saml2Response class in Kentor.AuthServices for sending responses is very limited at the moment, so there is no support for AttributeStatement nor for AuthnStatement. Support for sending AttributeStatement has been added.
Support might be added in a future release, but the main focus of the Kentor.AuthServices library is to be service provider that receives and parses SAML2 responses. The identity provider functionality for sending saml2 responses is of much lower priority.
If you need it, please add an issue on GitHub to get it into the backlog, or implement the features yourself and send a pull request. Pull requests are always welcome :-)
in the official trigger.io docs there seems to be no provision for custom http headers when it comes to the forge.file module. I need this so I can download files behind an http authentication scheme. This seems like an easy thing to add, if support is not already there.
any workarounds? any chance of a quick fix in the next update? I know I could use forge.request instead, but I'd like to keep a local copy (saveURL).
thanks
Unfortunately the file module just uses simple "download url" methods rather than a full HTTP request library, which makes it a fairly big task to add support for custom headers.
I've added a task to our backlog for this, but I don't have a timeframe for it being added.
Currently on iOS you can do basic auth by using urls in the form http://user:password#url.com in case that helps.
Maybe to avoid this you can configure your server differently, or have a proxy server in front that allows you to pass authentication details as get parameters?
An error occurred while trying to make a request to URI
'http://localhost:42083/Services/MyService.asmx'. This could be due to
attempting to access a service in a cross-domain way without a proper
cross-domain policy in place, or a policy that is unsuitable for SOAP
services. You may need to contact the owner of the service to publish
a cross-domain policy file and to ensure it allows SOAP-related HTTP
headers to be sent. This error may also be caused by using internal
types in the web service proxy without using the
InternalsVisibleToAttribute attribute. Please see the inner exception
for more details.
And the most peculiar thing about is that before it worked just fine, but when I changed just
a little thing in a stored procedure it throws this exception. That's weird! I'm getting a little more suspect against SOAP services for now. Anybody who has any ideas?
After having read you comment, please make sure you have deployed a cross-domain policy file. Tim has a great blog about it: http://timheuer.com/blog/archive/2008/04/06/silverlight-cross-domain-policy-file-snippet-intellisense.aspx. It is really an essential asset to obtain when starting SL to server communication.
Hope that helps.
Currently i enable UTF-8 as #Consumes("application/xml;charset=utf-8") in the RESTful Services for the different methods. I am interested to see if we can change this for all REST services with a single configuration change. We are using CXF, maybe there is something it provides?
Thanks
Ravi
The first question is are you sure you want to prevent any of your rest resources from accepting non-UTF-8 entities? Such an across the board proclamation feels like it could cause trouble down the road.
I'll admit that I haven't used CXF so I can't speak to those specifics. But I can think of one option each under the JAX-RS and Servlet APIs which might be along the lines of what you seek to accomplish.
Using the Servlet API: Depending on how you are deploying your application you might be able to create and inject a servlet filter. In the doFilter method, you can check the encoding of the request entity and continue on to the next part of the filter chain (ultimately to the rest application). If an improper entity is sent on the request, you would just set the appropriate HTTP 415 status onto the response and not invoke your rest application.
Using JAX-RS: Depending on how you parse/accept the entity body in your resources, you could create and inject a custom MessageBodyReader implementation. This reader could parse your entity, ensuring that it is UTF-8 only and throw an appropriate exception otherwise.