On Wed July 8 2009 12:39:08 am Glen Mazza wrote:
> No, actually I intentionally did not yank those, because they're in a
> different namespace that presumably CXF should ignore, right?
Not inside a policy, no. (this is one reason why mixing policy and
configuration is such a bad idea)
If you have a policy like:
<wsp:All>
....
</wsp:All>
Then per the policy spec, ALL of the policy elements (that aren't
wsp:Optional=true) must be applied. The policy spec doesn't say what the
namespaces and such of the individual policy assertion that would go into the
All are. Other specs (and company proprietary things) dictate those.
For example, a policy like:
<wsp:All>
<wsaw:UsingAddressing/>
</wsp:All>
If the addressing module isn't loaded, then there wouldn't be anything
registered to handle the UsingAddressing assertion. Should we just ignore it
and send the message out without addressing which would be against the
contract or should we fail with a "cannot implement the policy" type of
exception?
Anyway, if you want to leave them in, you should just need to add
wsp:Optional="true" to make them optional. Otherwise, you would need to
register stuff with the CXF Policy engine to support the Sun policy assertion
names.
In anycase, if you have a simple test case, feel free to add it to a JIRA. At
the very least, we should be able to make that error message a bit better to
at least specify which policy assertion is the issue.
Dan
> 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
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
