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.
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 <[email protected]>: >> 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 <[email protected]>: >>>> 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) <[email protected]>: >>>>>> 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 >>>> [email protected] - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>
