Hi
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?
Policy directives can only be ignored by a client runtime, when it chooses between multiple alternatives or when a given policy
assertion is marked as optional. Ex :
<Policy>
<ExactlyOnce>
<!-- Alt 1 -->
<All><A/><B/></All>
<!-- Alt 2 -->
<All><A/><B/><C/><D optional="true"/></All>
</ExactlyOnce>
</Policy>
One client can choose alternative 1 (it has to understand A & B), another one can choose alt2 amd it may not understand D. Yet
another client can choose alt2 and do exercise D. Note that Alt2 can be repleced with Alt21 && Alt22 :
<Policy>
<ExactlyOnce>
<!-- Alt 1 -->
<All><A/><B/></All>
<!-- Alt 21 -->
<All><A/><B/><C/></All>
<!-- Alt 22 -->
<All><A/><B/><C/><D/></All>
</ExactlyOnce>
</Policy>
As far as the service provider is concerned it really must to support A, B, C, D given that one of those clients will expect D be
supported, the one which chose Alt 22. Perhaps a service provider might choose to lazily initialize optional assertions but it has
to be able to meet the policy declaration in its contract
Not inside a policy, no. (this is one reason why mixing policy and
configuration is such a bad idea)
Agreed. If configuration does get injected inside a server policy instance then it would need to be removed at the publication time
(when we support java-first policies). For ex, an atribute like "private" can be used to mark such provate fragments.
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?
+1 for exception. Perhaps if it's an optional assertion then the exception can
be thrown later on if this assertion is requested
cheers, Sergey
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
