Always a new conduit been created and hence TlsParameter became null and
hence it try to pick it from defaultSSLSocketFactory...
After going through another thread, found a easy workaround for this, by
setting
conduit.getTarget().getAddress().setValue(https://www.example.com;) [Thanks
Dan!].
I m
Hi Dennis,
Is that really much worse than handling SwA signed attachments?
My understanding is that a BASE-64 encoding/decoding step is required for
the inlining case, which is not required for SwA.
Encryption seems confusing to me, though. Do you have to encrypt the
base64Binary data of the
Hi Colm,
On 03/24/2014 11:10 PM, Colm O hEigeartaigh wrote:
Is that really much worse than handling SwA signed attachments?
My understanding is that a BASE-64 encoding/decoding step is required for
the inlining case, which is not required for SwA.
Yes, I believe that's correct from what we
Hi.
I'm using CXF to create a service to request a token (SAML v1.1) to a C# STS
with custom claims types. I wrote a WSDL, generated the service from it, and
deployed the application in tomcat 7.
But i have this error:
Here is my WSDL:
?xml version=1.0 encoding=UTF-8 standalone=no?
What does your spring configuration look like? Also, do you have the
cxf-rt-ws-policy jar on the classpath?
Colm.
On Mon, Mar 24, 2014 at 12:07 PM, axelF cale...@orange.fr wrote:
Hi.
I'm using CXF to create a service to request a token (SAML v1.1) to a C#
STS
with custom claims types. I
I am using CXF 2.7.10 at the moment, however for the past few days I've been
experiencing a slowdown.
I'm using JaxWSProxyFactoryBean to create my service class as pointed out by
the user guide.
It works fine but however sometimes I do experience a slow down.
This is what I get from the
I have cxf-rt-ws-policy jar in my classpath.
Here the spring configuration:
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
Hi guys!
any idea about this?
regards
Guzmán
-Mensaje original-
From: Guzmán Llambías
Sent: Thursday, March 20, 2014 8:50 PM
To: users@cxf.apache.org
Subject: The https URL hostname does not match the Common Name (CN) on the
server certificate
Hi guys!
I’m trying to consume a
--
View this message in context:
http://cxf.547215.n5.nabble.com/Is-CXF-2-6-1-Compatible-with-Spring-3-2-8-tp5741776.html
Sent from the cxf-user mailing list archive at Nabble.com.
When the self signed certificate is generated, if they put CN=hostname you
have to connect with the same host name or it will not match. If you are
using the IP to connect for example, it will not match. The easiest way to
fix this is to create a local DNS entry on your client with the host name
Hi,
I am using SecurityTokenServiceProvider from CXF to generate SAML tokens.
The signed SAML contains:
ds:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1/
and
ds:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/
I would like to use SHA256 instead of SHA1.
You can change the signature algorithm via the SignatureProperties Object:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=services/sts/sts-core/src/main/java/org/apache/cxf/sts/SignatureProperties.java;hb=HEAD
This object should then be set on the StaticSTSProperties Object:
On Mar 24, 2014, at 6:26 AM, Dennis Sosnoski d...@sosnoski.com wrote:
Hi Colm,
A test-case would be great. I don't feel it's realistic to support it in
CXF 3.0.0 though, we can always get it to work in CXF 3.0.1. For CXF 3.0.0
I will leave the current functionality in place, but make the
2.6.x is really only tested with Spring 3.0.x. However, it should work fine
with 3.2.8 as 3.2.x doesn’t remove any of the deprecated methods that we used.
CXF 3.x will require Spring 3.2.6 or newer as we switched completely to the new
methods (so CXF will work with Spring 4 which did remove
At that point, it’s establishing the connection, handling any HTTPs handshake,
and then writing the data to the connection. Thus, it could be anything from
the server side’s backlog being full and thus having to wait, the server side
being slow reading some data, the HTTPs hand shake trying
Daniel,
Thanks for the reply. I'll look into your suggestion.
However, I still have another issue that I found due to this long delay.
I am using synchronous http transport. I have multiple requests calling the web
service on the server's end.
However, when there is one long running
We programmatically create jaxws client proxies in our code similiar to the
example below:
RetrieveAccountService retrieveAccountService = new
RetrieveAccountService(wsdlURL, serviceQName);
port = retrieveAccountService.getHttpBindingRetrieveAccount();
BindingProvider bp = (BindingProvider)port;
Can someone explain the importance of the wsdlLocation attribute in the
jaxws:endpoint element?
It seems to be optional; if I omit the wsdlLocation attribute the project
runs fine.
However if I include the attribute and point it to the WSDL file then I get
errors at startup:
18 matches
Mail list logo
