Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BDFA7DB6C for ; Wed, 4 Jul 2012 10:59:55 +0000 (UTC) Received: (qmail 52079 invoked by uid 500); 4 Jul 2012 10:59:55 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 51875 invoked by uid 500); 4 Jul 2012 10:59:54 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 51861 invoked by uid 99); 4 Jul 2012 10:59:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 10:59:53 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elakito@gmail.com designates 209.85.213.41 as permitted sender) Received: from [209.85.213.41] (HELO mail-yw0-f41.google.com) (209.85.213.41) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 10:59:47 +0000 Received: by yhr47 with SMTP id 47so8344535yhr.0 for ; Wed, 04 Jul 2012 03:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Tx6FRy8+/woeWweDERmZLjSBa8KNp9GtWZyT7mhfzZs=; b=DM2vL+daYppfFf4+0cZVvPTfiZHvH2sAxmQiAmB9zJWJP69f82mNYWvZ6qC99bfjyO Xm1Kc8IlQJvOklNPpgWGrSeTN0Vi2hnsl+zpYU+kLSd3DDKa2UozuQQz+raHotFr8kJF R9OS9T6gsJk9CL2NsZkclk4c2mWrTXMdryPgI2u/bAG3Tebn40RT7Xgf3L81AZmXBiar Gm6DiNgWWUAJfnAfnqtkFA+ljZQcSJ/FniN88eS/5Pdr5TO9/ana0N7x/ufU5yzsgF2+ Vl2XpqNNc6umz7PARq/28Mr8xENWeS98LGd5tH74wQ+aNoncsdxiuk72HdDnrgR7q8GR ceWw== MIME-Version: 1.0 Received: by 10.42.155.73 with SMTP id t9mr10804545icw.48.1341399566251; Wed, 04 Jul 2012 03:59:26 -0700 (PDT) Sender: elakito@gmail.com Received: by 10.64.24.208 with HTTP; Wed, 4 Jul 2012 03:59:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jul 2012 12:59:26 +0200 X-Google-Sender-Auth: 5mO4hTaw1jlAXaOsCVNh0N_f_j0 Message-ID: Subject: more flexibility in configuring httpconduit's tlsClientParameters in spring or blueprint? From: Aki Yoshida To: dev@cxf.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi, I haven been wondering about this for a while and I would like to hear your thoughts. Concretely, I am wondering if people are happy with the current file or resource based keystore instantiation provided by the tlsClientParameters's configuration schema. The current schema does not allow any bean referencing from within that structure. So, using the http's spring or blueprint namespace handlers that are based on this schema, you need to configure this entire structure. This makes it difficult to use this configuration handler If you have your own mechanism to get keystores and you can provide it as a bean or factory-bean reference. In such cases, one could directly configure the httpConduit and its tlsClientParameter as beans directly. Unfortunately, this doesn't work in blueprint because the blueprint bean element does not have the name attribute that can be used to configure the conduit's matching pattern. So, this is not practical. Besides, I think it's pain to configure beans directly when the specific namespace handlers are available. So what are the options? Is this an unusual use case? If this is not an unusual use case, should we add the reference attribute in some of those elements so that these can be optionally configured separately and referenced? Your comments are appreciated. Thanks. Regards, Aki