Jeff,
I like the idea of having pluggable validators. +1
When you add the Validator interface, can you provide guidance in the
javadoc to log trace when a header understood (and removed from the
NotUnderstoodHeaders Set).
For example it would be nice to see trace like:
JAXWSSoapHeaderValidator: The JAX-WS application handler,
mySample.handler, understands header {http://mySample}Foo.
Thanks,
Rich Scheuerle
IBM Web Services
Apache Axis2 ([EMAIL PROTECTED])
Jeff Barrett/Austin/[EMAIL PROTECTED] wrote on 07/11/2007 05:20:35 PM:
> Hi All,
>
> Here is my proposal for a mustUnderstand header validation framework.
>
> PLEASE NOTE the mustUnderstand processing is required for fixes we're
> trying to get in by 7/20 and which Geronimo needs.
>
> So, please take a look as soon as possible. If the overview seems OK,
> then I'll start on the code (this is post 1.3 work)
>
> Here's the Jira: https://issues.apache.org/jira/browse/AXIS2-2853
>
> Goals
> =====
>
> 1. Pluggable and extensible via configuration. Allow higher-level,
> non-engine components to participate in mustUnderstand validation.
> Examples include JAX-WS runtime and appliction handlers, WS-RM, and
> systems using Axis2 as a bus.
>
> 2. Support for actors/roles. Only mustUnderstand headers for
> actors/roles in which this node acts should be checked. Note that
> actors/roles would not be implemented immediately, but future support is
> taken into consideration in the design.
>
> OVERVIEW
> ========
>
> A list of soapHeaderValidators can optionally be configured in axis2.xml.
> The list of validators will be stored on the AxisConfiguration. Each
> validator has a method which takes a collection of not-yet-understood
> header QNames, a collection of String roles, and a MessageContext. The
> method will return a collection of header QNames based on the input
> parameter which are still not understood; that is, it removes any that it
> understands from the list.
>
> The AxisEngine.checkMustUnderstand() method will invoke each validator,
> passing in the collection of still-not-understood headers. If, after all
> the validators are called the collection is not empty, a mustUnderstand
> fault is thrown. The logic would be something like:
>
> String[] rolesActedIn = ... // list of actors/roles
> acted in.
> QName[] notUnderstoodHeaders = ... // list of all mU headers
> not marked as processed
> SOAPHeaderValidator[] validators =
> axisConfig.getSoapHeaderValidators();
> for (SOAPHeaderValidator validator : validators) {
> notUnderstoodHeaders =
> validator.validate(notUnderstoodHeaders, rolesActedIn, messageContext)
> }
>
> // If there are any not-understood headers after running the
> validators
> // throw an exception
> if (notUnderstoodHeader.length != 0) {
> throw notUnderstoodException
> }
>
> There is no API for the registration of understood headers; each
validator
>
> is responsible for deciding what it understands and removing it from the
> collection. For example, the JAXWS validator would look for a property
> (which it set earlier) on the AxisOperation containing the QNames for any
> JAXWS SEI header parameters and any headers understood by JAXWS
> application handlers. That property would be set by JAXWS on the
> AxisOperation during application startup.
>
> Configuration in axis2.xml
> --------------------------
>
> The <soapHeaderValidators> element is optional. If ommited then all
> mustUnderstand headers must be marked as processed by handlers, or a
> mustUnderstand fault will be thown (i.e. current
> AxisEngine.checkMustUnderstand semantics are unchanged)
>
> <soapHeaderValidators>
>
> <soapHeaderValidator>org.apache.axis2.jaxws.
> JAXWSSoapHeaderValidator</soapHeaderValidator>
>
> <soapHeaderValidator>my.other.validator.
> MySOAPHeaderValidator</soapHeaderValidator>
> </soapHeaderValidators>
>
>
>
> Thanks,
> Jeff
>
> IBM Software Group - WebSphere Web Services Development
> Phone: 512-838-4587 or Tie Line 678-4587
> Internet e-mail and Sametime ID: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
