Andrea Smyth <[EMAIL PROTECTED]> writes: > It simply chooses the first alternative that it sees can potentially > be supported - and that can be the empty alternative.
I see. It's hard to tell from the observable behavior that either alternative could have been chosen; I only see the client choosing /not/ to send addressing headers when the policy is optional, but, if I understand you correctly, CXF could have chosen the other alternative and sent the addressing headers, and been just as correct in doing so. > What do you mean with controlling whether or not the client sends > the addressing headers? Who, e.g. what interceptor or other > component should exert that control and when? I'm not sure yet. All these interacting components in CXF are too new to me to weigh in with any authority. > I'll see I can get around to doing it tomorrow. I don't expect this will change the behavior I'm seeing, as it looks as though in my case CXF is already choosing the alternative with the least assertions, which is also the "cheapest". > No, the feature is implemented in such a way that it rertieves the > policy engine and enables it if is not enabled yet. Ah, you're right. I see it working as you describe. > Do you mean with the WSPolicyFeature? No, I meant the set of elements that make sense within jaxws:features, unless they're all WSPolicyFeatures. But the LoggingFeature appearing in the example you referenced doesn't look like a WSPolicyFeature. -- Steven E. Harris
