I am assuming you ran a full build of CXF for this patch? I just tried to build 2.5.3 and I got a build failure in the tools/javato/ws project
org.apache.cxf.tools.java2ws.JavaToWSTest Is it normal for a fixed branch to have build breaks? On Wed, Feb 15, 2012 at 1:10 PM, Daniel Kulp <[email protected]> wrote: > On Wednesday, February 15, 2012 11:37:24 AM Jason Pell wrote: >> Daniel, >> >> Will you merge this to 2.5.x branch? So that it goes into the >> 2.5.3-SNAPSHOT? > > Just did. That said, not sure if the snapshots are deploying right now due > to issues with the Apache Jenkins setup. :-( > > Dan > >> >> I am building the trunk version for today, but will downgrade to >> 2.5.3-SNAPSHOT as soon as possible >> >> Thanks again >> >> On Wed, Feb 15, 2012 at 10:07 AM, Jason Pell <[email protected]> wrote: >> > Found it - https://issues.apache.org/jira/browse/CXF-4110 >> > >> > On Wed, Feb 15, 2012 at 9:37 AM, Jason Pell <[email protected]> wrote: >> >> Also in meantime can you direct me to the area of code you found the >> >> issue I would like to know this so I can do my own investigation if I >> >> have any further challenges >> >> >> >> Sent from my iPhone >> >> >> >> On Feb 15, 2012, at 5:18, Daniel Kulp <[email protected]> wrote: >> >>> On Tuesday, February 14, 2012 9:48:23 AM Daniel Kulp wrote: >> >>>> On Tuesday, February 14, 2012 4:29:06 PM Jason Pell wrote: >> >>>>> Hi, >> >>>>> >> >>>>> It does not seem to work for much other than SERVICE. I have not >> >>>>> tested all combinations so far, but so far all I have managed to have >> >>>>> working is SERVICE. >> >>>>> >> >>>>> I am now trying to associate Policy with one operation, while another >> >>>>> operation has no ws-security requirements at all. I have tried >> >>>>> BINDING_OPERATION, PORT_TYPE_OPERATION, neither of which work. >> >>>>> >> >>>>> Am certainly looking forward to your analysis. If you could point me >> >>>>> in the right direction of the code I would need to look at as I am >> >>>>> interested to understand this area of cxf as well >> >>>> >> >>>> Honestly, not quite sure where to look yet. The fact that the policy >> >>>> is >> >>>> properly exposed in the WSDL (via the ?wsdl url) shows that the policy >> >>>> is >> >>>> loaded fine and attached into the service model. The runtime SHOULD be >> >>>> using that just fine as it should be exactly the same as if the policy >> >>>> was >> >>>> loaded from a real WSDL. Thus, I'm not sure what would cause it yet. >> >>>> Probably will need to dig through the effective policy calculation >> >>>> stuff >> >>>> for both the wsdl first and non-wsdl cases to see where the policies >> >>>> are >> >>>> coming from and see what may be different. No idea yet. Again, >> >>>> very >> >>>> strange to see the policies in the wsdl, but no have them take affect. >> >>>> >> >>>> :-( >> >>> >> >>> OK. Figured this out. The policies and policy references themselves >> >>> were >> >>> properly added to the service model and thus showed up properly in the >> >>> generated WSDL. However, the "Description" (that holds the policies) >> >>> that is stored on the root Service object was not set on the endpoint >> >>> info or binding info and thus the references were not able to be >> >>> resolved. Just setting the description on those would fix this >> >>> problem. >> >>> >> >>> However, this is poor design. Those objects have a handle to the >> >>> Service >> >>> object. Thus, they don't need a copy of the description. They can just >> >>> call service.getDescription to get it. Thus, we won't need to make >> >>> sure we set it in the future. >> >>> >> >>> Running tests with that now. >> >>> >> >>> -- >> >>> Daniel Kulp >> >>> [email protected] - http://dankulp.com/blog >> >>> Talend Community Coder - http://coders.talend.com > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com
