I am assuming there will be a jira for this? Can you post the number to this post. A fix in 2.5.3 as well? I can run a snapshot of 2.5.3 until its released
Thanks again for looking at this really awesome work 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
