2012/2/7 Johan Edstrom <seij...@gmail.com>:
> Heh :)
>
> Not 100% sure we said the same thing here.
> I'm gone for about the next 4 days, I might start if, if you want to, please 
> go ahead.
> The customer I was out with that put the ticket in was basically looking for 
> jetty + ssl config.

Hi Johan,
I was confused with your remark but saw a lot of energy coming out of
it. And I thought you would be finishing it up by the weekend. I, on
the other hand, was thinking about working on it so that it can make
into 2.5.3 sometime.

I will look into the http client side and get back to you.

Regards, aki

>
> The client side stuff would not necessarily have to interfere with that, the 
> osgi servlet, now that is
> a potential different discussion, what is the right handling of SSL on that 
> side?
>
>
>
> On Feb 6, 2012, at 4:55 PM, Aki Yoshida wrote:
>
>> 2012/2/6 Johan Edstrom <seij...@gmail.com>:
>>> I got about as far as looking at the http:jetty schemas and was hoping I'd 
>>> be able to
>>> consolidate some of the parts there.
>>>
>>> I'm currently on the road 3h + on EST, so I think I might be fighting jet 
>>> lag for a day or so.
>>> I'll be available for testing and some banging on it at the very least 
>>> friday eve til monday morn,
>>> I suspect in-between as well.
>>
>> Okay. I will leave it to you then.  I just noticed that the actual
>> http-conf schema definition does not have spring dependency (i.e., not
>> using beans:identifierTypes etc). So, we don't need to modify the
>> schema and my earlier comment is invalid.  I was looking at the wrong
>> http-conf.xsd earlier and had the wrong assumption.
>>
>>> to be quite honest I got hijacked in the client changes Dan did for the 
>>> http transport,
>>> I kinda like those global conduits, but I'm thinking people might want a 
>>> very spring similar
>>> approach in http and httpj:?
>>>
>>
>> I haven't followed up on that change. I think the locally encapsulated
>> configuration is practical in some uses cases. In contrast, the
>> central configuration thing is a very useful thing when considering
>> the management of the sensitive information. In that direction, I
>> thought that we could also eventually use the apache HTTPClient (if we
>> could use it for the http conduit) and refer to it from the conduit?
>> In that case, we could reuse the http configurations in other
>> components. Dan once talked about using the apache http client. I
>> wanted to look into the current status of this work.
>>
>> regards aki
>>
>>
>>> /je
>>>
>>> On Feb 6, 2012, at 9:59 AM, Aki Yoshida wrote:
>>>
>>>> Hi Johan,
>>>>
>>>> Dan mentioned that you might have started working on this item. Please
>>>> let me know whether I can help here.
>>>>
>>>> Thanks.
>>>>
>>>> Regards, aki
>>>>
>>>> 2012/2/6 Daniel Kulp <dk...@apache.org>:
>>>>> On Monday, February 06, 2012 1:16:20 PM Aki Yoshida wrote:
>>>>>> Hi Dan,
>>>>>> I can look into this item using a similar approach used in ws-rm using
>>>>>> the merged schemas.
>>>>>> Let me know if you see some issues.
>>>>>
>>>>> Just make sure you work with Johan Edstrom.   I think he may have started
>>>>> looking into this a bit and I don't want to cause him any wasted time.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> thanks.
>>>>>> regards, aki
>>>>>>
>>>>>> 2012/2/3 Tony Su (Created) (JIRA) <j...@apache.org>:
>>>>>>> Blueprint http
>>>>>>> --------------
>>>>>>>
>>>>>>>                 Key: CXF-4084
>>>>>>>                 URL: https://issues.apache.org/jira/browse/CXF-4084
>>>>>>>             Project: CXF
>>>>>>>          Issue Type: New Feature
>>>>>>>          Components: Transports
>>>>>>>    Affects Versions: 2.5
>>>>>>>            Reporter: Tony Su
>>>>>>>            Priority: Minor
>>>>>>>             Fix For: 2.5.3, 2.6
>>>>>>>
>>>>>>>
>>>>>>> Some initial support for blueprint was provided in 2.4, but there are
>>>>>>> still additional schemas that need porting.
>>>>>>>
>>>>>>> Add support for http transport blueprint namespace handlers, parser and
>>>>>>> typeconverters
>>>>>>>
>>>>>>> --
>>>>>>> This message is automatically generated by JIRA.
>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>> administrators:
>>>>>>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>>>>>> For more information on JIRA, see: 
>>>>>>> http://www.atlassian.com/software/jira
>>>>> --
>>>>> Daniel Kulp
>>>>> dk...@apache.org - http://dankulp.com/blog
>>>>> Talend Community Coder - http://coders.talend.com
>>>
>

Reply via email to