Return-Path: 
 <cxf-dev-return-3309-apmail-incubator-cxf-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org
Received: (qmail 31340 invoked from network); 31 May 2007 09:46:21 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 31 May 2007 09:46:21 -0000
Received: (qmail 32493 invoked by uid 500); 31 May 2007 09:46:24 -0000
Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org
Received: (qmail 32449 invoked by uid 500); 31 May 2007 09:46:24 -0000
Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-dev@incubator.apache.org>
List-Id: <cxf-dev.incubator.apache.org>
Reply-To: cxf-dev@incubator.apache.org
Delivered-To: mailing list cxf-dev@incubator.apache.org
Received: (qmail 32440 invoked by uid 99); 31 May 2007 09:46:24 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 May 2007 02:46:24 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of sergey.beryozkin@iona.com
 designates 62.221.12.33 as permitted sender)
Received: from [62.221.12.33] (HELO emea-smg1.iona.com) (62.221.12.33)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 May 2007 02:46:19 -0700
Received: from emea-ems1.ionaglobal.com (dutec.ie [10.2.1.125])
	by emea-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
 l4VAfe4b014896
	for <cxf-dev@incubator.apache.org>; Thu, 31 May 2007 10:41:40 GMT
Received: from sberyoz ([10.2.1.195]) by emea-ems1.ionaglobal.com with
 Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 31 May 2007 10:45:55 +0100
Message-ID: <0df301c7a368$76ebce40$c301020a@pcgroupiona.com>
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>
References: <465D99CA.3000500@iona.com>
 <0ca601c7a2d3$6744f4c0$c301020a@pcgroupiona.com>
 <5A0E8895-2D41-40B0-9E0E-B66D6582AB4E@dushin.net>
 <0d0a01c7a2df$2acec870$c301020a@pcgroupiona.com> <465DDE71.8080308@iona.com>
Subject: Re: Http/s configuration Proposal
Date: Thu, 31 May 2007 10:45:47 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0DF0_01C7A370.D8AB7B50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-OriginalArrivalTime: 31 May 2007 09:45:55.0943 (UTC)
 FILETIME=[7C39AF70:01C7A368]
X-Virus-Checked: Checked by ClamAV on apache.org

------=_NextPart_000_0DF0_01C7A370.D8AB7B50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Polar

Finally I inderstand. This looks good. Changing the name of the bean =
name to a more neutral name is also a good idea.

Thanks, Sergey

P.S I had to look into the English dictionary,=20
"To fret" is often used as a verb, meaning simply "to press down the =
string behind a fret."

This made me smile :-)


> Hi Sergey,
>=20
> Glad you brought this code up. I think this is what it should be:
>=20
> private static final String HTTP_LISTENER_NAME =3D "..."; <proposal =
still=20
> sought>
>=20
> private String listenerBeanName;
> // The tlsParams will be null if not used.
> private TLSServerParameters tlsParams =3D
>            initTLSServerParameters();
>    =20
> .....
>=20
> public void configureBean(Object beanInstance) {
>    String beanName =3D getBeanName(beanInstance);
>    if (listenerBeanName.equals(beanName)
>        && tlsParams !=3D null)
>    {
>           // Is there a spring configuration?
>           super.configureBean(beanInstance);
>           // Make decision to override.
>           if (isSetTLSParameters()) {
>                LOG.fine("Overriding spring configuration of=20
> TLSParameters for " + listenerBeanName);
>                 // maybe throw configuration exception?
>           }
>           // Override
>           HTTPListenerConfigBean bean =3D
>                   (HTTPListenerConfigBean)beanInstance;
>           bean.setTLSParameters(tlsParams);
>    }
> }
>=20
> The big difference here, is that you call super.configureBean() first=20
> instead of last. Calling it
> first makes you figure out if the application deployer actually=20
> configured it using Spring and
> XML. Your configurer can choose to ignore that if you wish, because =
it's=20
> your code.
>=20
> Having the the super.configureBean() in order to get what you wanted=20
> forced the code in
> CXF to ignore any call to setSslServer(). I believe that is wrong. CXF =

> should do what you
> tell it to, and you should be notified if it isn't going to work.
>=20
> The above setTLSParameters will work, regardless of whether the=20
> TLSParameters are set or not
> because the configuration will not be "finalized" on the bean in=20
> question until after
> Configurer. configureBean() is done.
>=20
>> Ok, given the above explanation, what is going to change for users=20
>> wishing to publish two providers serving different contexts on the=20
>> same 9090 port and configure the ssl setting of the port=20
>> programmatically? Sorry I don't understand you saying  no need to=20
>> write this expression per each endpoint.publish, only if once needs =
to=20
>> do it programmatically
>>
> Nothing, unless people where doing trying to set two different =
keystores=20
> on two different destinations that
> were on the same Port. Actually what was happening in that case, is =
that=20
> only the first configuration was
> applicable. So, if Destination 1 wanted to publish on port 9000 and=20
> wanted to authenticate as "Alice" and
> Destination 2 wanted to publish on port 9000 and wanted to =
authenticate=20
> as "Bob", Destination 2 was out
> of luck in that case, and actually authentiicated as "Alice" without =
so=20
> much as a warning.
>=20
> Cheers,
> -Polar
>=20
>> Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> On May 30, 2007, at 11:58 AM, Sergey Beryozkin wrote:
>>>
>>>> With your proposal one needs to write this complex expression in =20
>>>> addition per every endpoint registration :
>>>>
>>>>> ((JettyHTTPDestination)endpoint.getServer().getDestination()).
>>>>>                    getJettyHTTPServerEngine=20
>>>>> ().setTLSServerParameters(parms);
>>>>
>>>> Does it mean that for https://localhost:9000/bar one can point to =20
>>>> one keystore for ex and for
>>>> https://localhost:9000/foo one can point to another keystore ? What =
=20
>>>> is the point of calling
>>>> setTLSServerParameters(parms); per every endpoint sharing the same  =

>>>> port ?
>>>
>>> No, one does not need to write this expression for each =20
>>> endpoint.publish.  You only need to do this if you want to configure =
=20
>>> the server engine programatically.  I think the point is, you should =
=20
>>> be doing that on the server engine instance directly, not indirectly =
=20
>>> through the Destination.
>>>
>>> Just to allay any fears, this is being done precisely to support the =
=20
>>> use case:
>>>
>>> Endpoint.publish("https://www.acme.com:9090/foo", ...);
>>> Endpoint.publish("https://www.acme.com:9090/bar", ...);
>>>
>>> which is currently broken in CXF.
>>>
>>> I think we're in agreement here.
>>>
>>> -Fred=20
>>
>
------=_NextPart_000_0DF0_01C7A370.D8AB7B50--