You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by LBC <lb...@yahoo.com.INVALID> on 2015/06/25 12:11:55 UTC
problems using CXF as a JAX-RS 2.0 client
hi,
I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
thanks,--Lawrence
-----import javax.ws.rs.client.Client;import javax.ws.rs.client.ClientBuilder;import javax.ws.rs.client.Invocation;import javax.ws.rs.client.WebTarget;import javax.ws.rs.core.Response;
import org.slf4j.Logger;import org.slf4j.LoggerFactory;
public class TestJaxRsClient{ private final static Logger logger = LoggerFactory.getLogger(TestJaxRsClient.class); public static void main(String[] args) { try { Client client = ClientBuilder.newBuilder().newClient(); WebTarget target = client.target("https://quandl.com/api/v1/datasets/WIKI"); target = target.path("AAPL.csv") .queryParam("trim_start", "2013-02-04") .queryParam("trim_end", "2013-02-06") .queryParam("collapse", "daily"); logger.info( String.format("target = [%s]", target.toString()) ); Invocation.Builder builder = target.request(); Response response = builder.get(); logger.info( String.format("response status code = [%d]", response.getStatus()) ); } catch (Exception e) { e.printStackTrace(); } }
}
---- <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-frontend-jaxws</artifactId> <version>3.0.2</version> </dependency>
----02:20:11.211 [main] DEBUG o.apache.cxf.common.logging.LogUtils - Using org.apache.cxf.common.logging.Slf4jLogger for logging.02:20:11.242 [main] INFO c.m.p.cxf.jaxrs.TestJaxRsClient - target = [org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl@33319df3]02:20:11.461 [main] DEBUG o.a.c.jaxrs.provider.ProviderFactory - Problem with creating the default provider org.apache.cxf.jaxrs.provider.json.JSONProvider: org.apache.cxf.jaxrs.provider.json.JSONProvider02:20:11.469 [main] DEBUG o.a.c.j.model.AbstractResourceInfo - Injecting a custom context org.apache.cxf.jaxrs.ext.MessageContext, ContextProvider is required for this type02:20:11.476 [main] DEBUG o.a.c.j.model.AbstractResourceInfo - Injecting a custom context org.apache.cxf.jaxrs.ext.MessageContext, ContextProvider is required for this type02:20:11.480 [main] DEBUG o.a.c.j.model.AbstractResourceInfo - Injecting a custom context org.apache.cxf.jaxrs.ext.MessageContext, ContextProvider is required for this type02:20:11.481 [main] DEBUG o.a.c.j.model.AbstractResourceInfo - Injecting a custom context org.apache.cxf.jaxrs.ext.MessageContext, ContextProvider is required for this type02:20:11.512 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.ws.policy.PolicyOutInterceptor@55fcde1f to phase setup02:20:11.513 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.interceptor.MessageSenderInterceptor@4c5af153 to phase prepare-send02:20:11.513 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.interceptor.MessageSenderInterceptor@4c5af153 to phase prepare-send02:20:11.514 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.jaxrs.client.spec.ClientRequestFilterInterceptor@5411cd7 to phase pre-logical02:20:11.530 [main] DEBUG o.a.cxf.transport.http.HTTPConduit - Conduit '{https://quandl.com/api/v1/datasets/WIKI/AAPL.csv}WebClient.http-conduit' has been (re)configured for plain http.02:20:11.531 [main] DEBUG o.a.cxf.transport.http.HTTPConduit - No Trust Decider configured for Conduit '{https://quandl.com/api/v1/datasets/WIKI/AAPL.csv}WebClient.http-conduit'02:20:11.531 [main] DEBUG o.a.cxf.transport.http.HTTPConduit - No Auth Supplier configured for Conduit '{https://quandl.com/api/v1/datasets/WIKI/AAPL.csv}WebClient.http-conduit'02:20:11.531 [main] DEBUG o.a.cxf.transport.http.HTTPConduit - Conduit '{https://quandl.com/api/v1/datasets/WIKI/AAPL.csv}WebClient.http-conduit' has been configured for plain http.02:20:11.531 [main] DEBUG o.a.cxf.transport.http.HTTPConduit - registering incoming observer: org.apache.cxf.jaxrs.client.ClientMessageObserver@77f7b37702:20:11.532 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain org.apache.cxf.phase.PhaseInterceptorChain@7b6626e3 was created. Current flow: setup [PolicyOutInterceptor] pre-logical [ClientRequestFilterInterceptor] prepare-send [MessageSenderInterceptor]
02:20:11.532 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.ws.policy.PolicyOutInterceptor@55fcde1f02:20:11.532 [main] DEBUG o.a.c.ws.policy.PolicyOutInterceptor - No binding operation info.02:20:11.532 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.jaxrs.client.spec.ClientRequestFilterInterceptor@5411cd702:20:11.532 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.interceptor.MessageSenderInterceptor@4c5af15302:20:11.605 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The location of the key store has not been set via a system parameter or through configuration so the default value of C:\Users\LBC/.keystore will be used.02:20:11.605 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The key store password has not been set via a system property or through configuration, reading data from the keystore will fail.02:20:11.605 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The key password has not been set via a system property or through configuration, reading data from the keystore will fail.02:20:11.605 [main] WARN o.a.c.t.h.HttpsURLConnectionFactory - Default key managers cannot be initialized: C:\Users\LBC\.keystore (The system cannot find the file specified)02:20:11.715 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The cipher suites have not been configured, falling back to cipher suite filters.02:20:11.715 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The cipher suite filters have not been configured, falling back to default filters.02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - Ciphersuite include filter: .*02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - Ciphersuite include filter: .*_NULL_.*02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - Ciphersuite include filter: .*_anon_.*02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_RSA_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.716 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_RSA_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.717 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_RSA_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_DHE_DSS_WITH_AES_128_CBC_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_ECDSA_WITH_RC4_128_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_RSA_WITH_RC4_128_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_WITH_RC4_128_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_ECDSA_WITH_RC4_128_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_RSA_WITH_RC4_128_SHA cipher suite is included by the filter.02:20:11.718 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_WITH_RC4_128_MD5 cipher suite is included by the filter.02:20:11.719 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_EMPTY_RENEGOTIATION_INFO_SCSV cipher suite is included by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_DH_anon_WITH_AES_128_CBC_SHA256 cipher suite is excluded by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_anon_WITH_AES_128_CBC_SHA cipher suite is excluded by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite is excluded by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_anon_WITH_RC4_128_SHA cipher suite is excluded by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DH_anon_WITH_RC4_128_MD5 cipher suite is excluded by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA cipher suite is excluded by the filter.02:20:11.720 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DH_anon_WITH_3DES_EDE_CBC_SHA cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_RSA_WITH_NULL_SHA256 cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_ECDSA_WITH_NULL_SHA cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDHE_RSA_WITH_NULL_SHA cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_WITH_NULL_SHA cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_ECDSA_WITH_NULL_SHA cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_RSA_WITH_NULL_SHA cipher suite is excluded by the filter.02:20:11.721 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_ECDH_anon_WITH_NULL_SHA cipher suite is excluded by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_WITH_NULL_MD5 cipher suite is excluded by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_WITH_DES_CBC_SHA cipher suite is included by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DHE_RSA_WITH_DES_CBC_SHA cipher suite is included by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DHE_DSS_WITH_DES_CBC_SHA cipher suite is included by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DH_anon_WITH_DES_CBC_SHA cipher suite is excluded by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_EXPORT_WITH_RC4_40_MD5 cipher suite is included by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 cipher suite is excluded by the filter.02:20:11.722 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_RSA_EXPORT_WITH_DES40_CBC_SHA cipher suite is included by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA cipher suite is included by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA cipher suite is included by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA cipher suite is excluded by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_WITH_RC4_128_SHA cipher suite is included by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_WITH_RC4_128_MD5 cipher suite is included by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_WITH_3DES_EDE_CBC_SHA cipher suite is included by the filter.02:20:11.723 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_WITH_3DES_EDE_CBC_MD5 cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_WITH_DES_CBC_SHA cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_WITH_DES_CBC_MD5 cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_EXPORT_WITH_RC4_40_SHA cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_EXPORT_WITH_RC4_40_MD5 cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 cipher suite is included by the filter.02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The enabled cipher suites have been filtered down to [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5].02:20:11.724 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The excluded cipher suites have been filtered down to [TLS_DH_anon_WITH_AES_128_CBC_SHA256, TLS_ECDH_anon_WITH_AES_128_CBC_SHA, TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_RC4_128_SHA, SSL_DH_anon_WITH_RC4_128_MD5, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_NULL_SHA256, TLS_ECDHE_ECDSA_WITH_NULL_SHA, TLS_ECDHE_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_SHA, TLS_ECDH_ECDSA_WITH_NULL_SHA, TLS_ECDH_RSA_WITH_NULL_SHA, TLS_ECDH_anon_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA]. 02:20:11.725 [main] DEBUG o.a.c.t.h.HttpsURLConnectionFactory - The cipher suites have been set to TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. 02:20:11.734 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor@5c07481f to phase prepare-send-ending02:20:11.734 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain org.apache.cxf.phase.PhaseInterceptorChain@7b6626e3 was modified. Current flow: setup [PolicyOutInterceptor] pre-logical [ClientRequestFilterInterceptor] prepare-send [MessageSenderInterceptor] prepare-send-ending [MessageSenderEndingInterceptor]
02:20:11.735 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor@5c07481f02:20:11.736 [main] DEBUG o.apache.cxf.transport.http.Headers - Accept: */*02:20:11.736 [main] DEBUG o.a.cxf.transport.http.HTTPConduit - No Trust Decider for Conduit '{https://quandl.com/api/v1/datasets/WIKI/AAPL.csv}WebClient.http-conduit'. An afirmative Trust Decision is assumed.02:20:12.382 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.ws.policy.PolicyInInterceptor@7e79a857 to phase receive02:20:12.382 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.jaxrs.client.WebClient$ClientAsyncResponseInterceptor@651b289f to phase unmarshal02:20:12.384 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Adding interceptor org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@c91d4b5 to phase pre-protocol-frontend02:20:12.385 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain org.apache.cxf.phase.PhaseInterceptorChain@3a23bd85 was created. Current flow: receive [PolicyInInterceptor] pre-protocol-frontend [ClientResponseFilterInterceptor] unmarshal [ClientAsyncResponseInterceptor]
02:20:12.386 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.ws.policy.PolicyInInterceptor@7e79a85702:20:12.404 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@c91d4b502:20:12.404 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.jaxrs.client.WebClient$ClientAsyncResponseInterceptor@651b289f02:20:12.408 [main] INFO c.m.p.cxf.jaxrs.TestJaxRsClient - response status code = [301]
Re: problems using CXF as a JAX-RS 2.0 client
Posted by LBC <lb...@yahoo.com.INVALID>.
I just saw the comment from Daniel Kulp on CXF-6475. Great find, thanks! I'll comment further on the JIRA ticket.
On Thursday, June 25, 2015 5:41 PM, LBC <lb...@yahoo.com.INVALID> wrote:
I modified the code to reveal the URIs and updated CXF-6475 with a comment. The built URIs from CXF and Jersey appear to be identical.
Unfortunately, I don't have the cycles w/ work to dig into it further than that, but I'll Brian Risk from Quandl support (the WS provider) to comment on what conditions would generate the 301 response.
On Thursday, June 25, 2015 2:10 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
Thanks for the analysis so far. It does not really bring us any closer
to finding where the problem is.
Try the following:
1. Compare URIs created by CXF and Jersey. There has to be some
difference, possibly a subtle one somewhere.
2. Check if CXF sends multiple requests - may be the target service
challenges the client or auto redirects.
3. Find out from the provider under what conditions 301 is returned and
if necessary ask them to provide with some more details.
4. Rewrite the code a bit and try CXF WebClient and initialize it with
LoggingFeature (a note to myself - add a JAX-RS Feature wrapper around
CXF Feature)
The client code is very straightforward and I do not see the reason it
would not work. Please keep investigating
Cheers, Sergey
On 25/06/15 21:08, LBC wrote:
> I've attached the tcpdump files to the ticket: https://issues.apache.org/jira/browse/CXF-6475
>
> BTW, I don't have access to the server side as I'm the WS consumer. I do have a support agreement with the WS provider though so if necessary I can possibly request logs from them. However, it would seem this issue has more to do w/ CXF.
>
>
>
> On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>
> Hi
>
> You could've just posted a link to CXF-6475 to make it easier to read
> this message.
>
> I do not see where the issue is. HttpConduit logging is a bit confusing
> indeed because there's a number of attempts to set TLS client parameters
> but it does not mean that HTTPS is not used.
> Can you trace the content of the request in a plain tcp trace utility ?
> I'd say that no.
>
> 301 vs 200 does not mean it is not HTTPS.
>
> The clue should be on the server side. Why 301, perhaps CXF produces a
> slightly different URI compared to Jersey ? Does the server depend on
> the order of the query parameters ?
>
> Please investigate and let me know
> Sergey
>
> On 25/06/15 11:11, LBC wrote:
>> hi,
>> I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
>> thanks,--Lawrence
>
>
>
>
>
>
Re: problems using CXF as a JAX-RS 2.0 client
Posted by LBC <lb...@yahoo.com.INVALID>.
I modified the code to reveal the URIs and updated CXF-6475 with a comment. The built URIs from CXF and Jersey appear to be identical.
Unfortunately, I don't have the cycles w/ work to dig into it further than that, but I'll Brian Risk from Quandl support (the WS provider) to comment on what conditions would generate the 301 response.
On Thursday, June 25, 2015 2:10 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
Thanks for the analysis so far. It does not really bring us any closer
to finding where the problem is.
Try the following:
1. Compare URIs created by CXF and Jersey. There has to be some
difference, possibly a subtle one somewhere.
2. Check if CXF sends multiple requests - may be the target service
challenges the client or auto redirects.
3. Find out from the provider under what conditions 301 is returned and
if necessary ask them to provide with some more details.
4. Rewrite the code a bit and try CXF WebClient and initialize it with
LoggingFeature (a note to myself - add a JAX-RS Feature wrapper around
CXF Feature)
The client code is very straightforward and I do not see the reason it
would not work. Please keep investigating
Cheers, Sergey
On 25/06/15 21:08, LBC wrote:
> I've attached the tcpdump files to the ticket: https://issues.apache.org/jira/browse/CXF-6475
>
> BTW, I don't have access to the server side as I'm the WS consumer. I do have a support agreement with the WS provider though so if necessary I can possibly request logs from them. However, it would seem this issue has more to do w/ CXF.
>
>
>
> On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>
> Hi
>
> You could've just posted a link to CXF-6475 to make it easier to read
> this message.
>
> I do not see where the issue is. HttpConduit logging is a bit confusing
> indeed because there's a number of attempts to set TLS client parameters
> but it does not mean that HTTPS is not used.
> Can you trace the content of the request in a plain tcp trace utility ?
> I'd say that no.
>
> 301 vs 200 does not mean it is not HTTPS.
>
> The clue should be on the server side. Why 301, perhaps CXF produces a
> slightly different URI compared to Jersey ? Does the server depend on
> the order of the query parameters ?
>
> Please investigate and let me know
> Sergey
>
> On 25/06/15 11:11, LBC wrote:
>> hi,
>> I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
>> thanks,--Lawrence
>
>
>
>
>
>
Re: problems using CXF as a JAX-RS 2.0 client
Posted by Sergey Beryozkin <sb...@gmail.com>.
FYI, I've added an 'http.autoredirect' property that can used to enable
an auto-redirect if really needed by passing it directly to 2.0
Configurable (Client, WebTarget).
Sergey
On 25/06/15 22:09, Sergey Beryozkin wrote:
> Thanks for the analysis so far. It does not really bring us any closer
> to finding where the problem is.
>
> Try the following:
> 1. Compare URIs created by CXF and Jersey. There has to be some
> difference, possibly a subtle one somewhere.
>
> 2. Check if CXF sends multiple requests - may be the target service
> challenges the client or auto redirects.
>
> 3. Find out from the provider under what conditions 301 is returned and
> if necessary ask them to provide with some more details.
>
> 4. Rewrite the code a bit and try CXF WebClient and initialize it with
> LoggingFeature (a note to myself - add a JAX-RS Feature wrapper around
> CXF Feature)
>
> The client code is very straightforward and I do not see the reason it
> would not work. Please keep investigating
>
> Cheers, Sergey
>
>
> On 25/06/15 21:08, LBC wrote:
>> I've attached the tcpdump files to the ticket:
>> https://issues.apache.org/jira/browse/CXF-6475
>>
>> BTW, I don't have access to the server side as I'm the WS consumer. I
>> do have a support agreement with the WS provider though so if
>> necessary I can possibly request logs from them. However, it would
>> seem this issue has more to do w/ CXF.
>>
>>
>>
>> On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin
>> <sb...@gmail.com> wrote:
>>
>>
>> Hi
>>
>> You could've just posted a link to CXF-6475 to make it easier to read
>> this message.
>>
>> I do not see where the issue is. HttpConduit logging is a bit confusing
>> indeed because there's a number of attempts to set TLS client parameters
>> but it does not mean that HTTPS is not used.
>> Can you trace the content of the request in a plain tcp trace utility ?
>> I'd say that no.
>>
>> 301 vs 200 does not mean it is not HTTPS.
>>
>> The clue should be on the server side. Why 301, perhaps CXF produces a
>> slightly different URI compared to Jersey ? Does the server depend on
>> the order of the query parameters ?
>>
>> Please investigate and let me know
>> Sergey
>>
>> On 25/06/15 11:11, LBC wrote:
>>> hi,
>>> I'm having problems establishing a secure connection using CXF/JVM
>>> defaults. Hopefully it's just a simple configuration issue. Below
>>> is the generic JAX-RS 2.0 code, along with the associated Maven
>>> dependency, and the log output demonstrating the problem. Even though
>>> I'm specifying a "https" URL, it seems CXF is making the request via
>>> HTTP and thus yielding a 301 HTTP response code. I'm running on JDK
>>> 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield
>>> a similar result. Running the same test with the Jersey 2.x JAX-RS
>>> client yields the correct 200 HTTP response code.
>>> thanks,--Lawrence
>>
>>
>>
>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: problems using CXF as a JAX-RS 2.0 client
Posted by Sergey Beryozkin <sb...@gmail.com>.
Thanks for the analysis so far. It does not really bring us any closer
to finding where the problem is.
Try the following:
1. Compare URIs created by CXF and Jersey. There has to be some
difference, possibly a subtle one somewhere.
2. Check if CXF sends multiple requests - may be the target service
challenges the client or auto redirects.
3. Find out from the provider under what conditions 301 is returned and
if necessary ask them to provide with some more details.
4. Rewrite the code a bit and try CXF WebClient and initialize it with
LoggingFeature (a note to myself - add a JAX-RS Feature wrapper around
CXF Feature)
The client code is very straightforward and I do not see the reason it
would not work. Please keep investigating
Cheers, Sergey
On 25/06/15 21:08, LBC wrote:
> I've attached the tcpdump files to the ticket: https://issues.apache.org/jira/browse/CXF-6475
>
> BTW, I don't have access to the server side as I'm the WS consumer. I do have a support agreement with the WS provider though so if necessary I can possibly request logs from them. However, it would seem this issue has more to do w/ CXF.
>
>
>
> On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>
> Hi
>
> You could've just posted a link to CXF-6475 to make it easier to read
> this message.
>
> I do not see where the issue is. HttpConduit logging is a bit confusing
> indeed because there's a number of attempts to set TLS client parameters
> but it does not mean that HTTPS is not used.
> Can you trace the content of the request in a plain tcp trace utility ?
> I'd say that no.
>
> 301 vs 200 does not mean it is not HTTPS.
>
> The clue should be on the server side. Why 301, perhaps CXF produces a
> slightly different URI compared to Jersey ? Does the server depend on
> the order of the query parameters ?
>
> Please investigate and let me know
> Sergey
>
> On 25/06/15 11:11, LBC wrote:
>> hi,
>> I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
>> thanks,--Lawrence
>
>
>
>
>
>
Re: problems using CXF as a JAX-RS 2.0 client
Posted by LBC <lb...@yahoo.com.INVALID>.
I've attached the tcpdump files to the ticket: https://issues.apache.org/jira/browse/CXF-6475
BTW, I don't have access to the server side as I'm the WS consumer. I do have a support agreement with the WS provider though so if necessary I can possibly request logs from them. However, it would seem this issue has more to do w/ CXF.
On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
Hi
You could've just posted a link to CXF-6475 to make it easier to read
this message.
I do not see where the issue is. HttpConduit logging is a bit confusing
indeed because there's a number of attempts to set TLS client parameters
but it does not mean that HTTPS is not used.
Can you trace the content of the request in a plain tcp trace utility ?
I'd say that no.
301 vs 200 does not mean it is not HTTPS.
The clue should be on the server side. Why 301, perhaps CXF produces a
slightly different URI compared to Jersey ? Does the server depend on
the order of the query parameters ?
Please investigate and let me know
Sergey
On 25/06/15 11:11, LBC wrote:
> hi,
> I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
> thanks,--Lawrence
Re: problems using CXF as a JAX-RS 2.0 client
Posted by LBC <lb...@yahoo.com.INVALID>.
Sorry, I didn't realize the formatting would get messed up like that. I forgot to mention that the 301 and 200 responses I was seeing, I confirmed also through curl and wget. I've included these outputs in the ticket (https://issues.apache.org/jira/browse/CXF-6475). I'll work on grabbing the TCP dumps and reply with that soon.
On Thursday, June 25, 2015 3:55 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
Hi
You could've just posted a link to CXF-6475 to make it easier to read
this message.
I do not see where the issue is. HttpConduit logging is a bit confusing
indeed because there's a number of attempts to set TLS client parameters
but it does not mean that HTTPS is not used.
Can you trace the content of the request in a plain tcp trace utility ?
I'd say that no.
301 vs 200 does not mean it is not HTTPS.
The clue should be on the server side. Why 301, perhaps CXF produces a
slightly different URI compared to Jersey ? Does the server depend on
the order of the query parameters ?
Please investigate and let me know
Sergey
On 25/06/15 11:11, LBC wrote:
> hi,
> I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
> thanks,--Lawrence
Re: problems using CXF as a JAX-RS 2.0 client
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
You could've just posted a link to CXF-6475 to make it easier to read
this message.
I do not see where the issue is. HttpConduit logging is a bit confusing
indeed because there's a number of attempts to set TLS client parameters
but it does not mean that HTTPS is not used.
Can you trace the content of the request in a plain tcp trace utility ?
I'd say that no.
301 vs 200 does not mean it is not HTTPS.
The clue should be on the server side. Why 301, perhaps CXF produces a
slightly different URI compared to Jersey ? Does the server depend on
the order of the query parameters ?
Please investigate and let me know
Sergey
On 25/06/15 11:11, LBC wrote:
> hi,
> I'm having problems establishing a secure connection using CXF/JVM defaults. Hopefully it's just a simple configuration issue. Below is the generic JAX-RS 2.0 code, along with the associated Maven dependency, and the log output demonstrating the problem. Even though I'm specifying a "https" URL, it seems CXF is making the request via HTTP and thus yielding a 301 HTTP response code. I'm running on JDK 7 (jdk1.7.0_51). I've tried CXF 3.0.2, 3.0.3, and 3.1.1. All yield a similar result. Running the same test with the Jersey 2.x JAX-RS client yields the correct 200 HTTP response code.
> thanks,--Lawrence