No, actually I intentionally did not yank those, because they're in a different namespace that presumably CXF should ignore, right? I come from the Apache FOP environment where formatting commands of an unknown namespace are just ignored--they are assumed to be specialized proprietary commands for other competitor processors to FOP. (OTOH, perhaps it should fail with an error or give a warning if it can't process a particular namespace...that might help save some people who misspell a WS-SecPol or other official namespace and hence have their Policy elements skipped by CXF without realizing it.)
But to test, I did just yank the ValidatorConfiguration from the local WSDL file that the SOAP client reads via the DoubleItService.java class and got the same error message. (The Callback handler you see for the client-side config in the Metro example was never present in the CXF client code--it just has access to the service WSDL.) mvn exec:exec with the -X option and using a logging.properties file didn't provide any more useful information. I'll start debugging without the Metro-specific elements to see if I can find anything else. Thanks, Glen dkulp wrote: > > > Hate to ask the obvious, but did you yank out the Metro specific policies > from > the wsdl? Example: the ValidatorConfiguration policy and CallbackHandler > and > such? > > Not sure if upping logging levels will help. I've started going through > and > tried to make it output better error messages that provide more details > when > policies cannot be met, but apparently this error message got through. > It > definitely needs some work to make sure it will track what policies could > not > be satisfied to make the error message a bit better. > > Dan > -- View this message in context: http://www.nabble.com/Debugging-%22None-of-the-policy-alternatives-can-be-satisfied%22-WS-SecPol-error-tp24384805p24385227.html Sent from the cxf-user mailing list archive at Nabble.com.
