Hi Dan, thanks for extracting that namespace part and putting it into api. As talked on #cxf today, it's all working fine. I also added wsdl.xsd to the list so that http-conf also works from the start.
regards, aki p.s. you are right, that CXFCoreNSH had more. Last night, i didn't scroll down that file enough to see the rest :(. 2012/5/25 Daniel Kulp <[email protected]>: > > I just committed some changed for this. Can you give it a spin and see if > that helps? > > Dan > > > On Thursday, May 24, 2012 10:25:06 PM Daniel Kulp wrote: >> On Friday, May 25, 2012 12:14:54 AM Aki Yoshida wrote: >> > Hi, >> > doing some offline setup tests, I noticed that those core >> > configuration schemas are in api but the location resolver code >> > CXFCoreNamespaceHandler is in rt/core. >> > >> > I noticed this offline loading problem when I used the 2.6.x >> > individual bundles offline. >> > >> > We need to move this org.apache.cxf.bus.blueprint package to api or >> > move only this class in a different package in api. >> > >> > The latter approach seems to be a simpler one. But package name >> > org.apache.cxf.configuration.blueprint is already taken by rt/core. I >> > don't know if we should move this package to api and put this resolver >> > there or create a new package. >> > >> > Or is there another idea? >> >> Well, we cannot move the whole class as the processing of the "core" stuff >> is in there. Thus, all of the Bus things would need to move and such as >> well. I think it needs to be split with just the "core" in a handler >> loaded from there and all the utility schemas loaded from a namespace >> handler in api. I'll try tackling that in the morning. The package in >> API can be anything as it can also be completely private/not exported. > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
