Hi guys:
Comments inline.
Jeff Barrett wrote:
Given that discussion, I believe the suggested approach here is to add a
handler in the distpatch phase that will mark the headers as processed,
even though they are not actually processed yet. In our JAX-WS case, that
handler would mark headers as processed for:
- Headers that correspond to parameters on the SEI
- Headers that will be processed by JAX-WS application handlers
>
The headers would not actually be consumed until the JAX-WS message
receiver is invoked, but the headers would be marked as processed by the
new handler in order to pass mustUnderstand checks in the engine. Did I
understand that correctly?
That is certainly one way of doing it, and not even necessarily a bad
one. But keep in mind that there are two parts to this design - 1) the
Handler itself, and 2) the APIs and data structures that are used to get
the header information to the Handler (i.e. particular context
properties, etc). The second part is going to be needed anyway, and we
should design that appropriately - I think the technique of registering
QNames with the AxisOperation (or AxisService even) seems fine. That
seems like the big API issue to me, and once that's done it doesn't so
much matter whether there is a particular Handler to do the job or
whether the AxisEngine itself does it... and I think I prefer the
latter. We're going to need the exact same functionality to get
soap:header working right with ADB, so I'd rather leave it core.
Beyond that, there are a couple more longer-term considerations (which my
commit did not address):
1) The mustUnderstand processing also needs to consider the SOAP
actor/role, which Axis2 currently does not do. Only mustUnderstand
headers for roles in which the node acts should be checked; mustUnderstand
headers for roles the node does not act in should be ignored. So, if
there's a mustUnderstand header for actor="notThisRole" and this node
doesn't act in that role, then that header somehow needs to be ignored by
the Axis2 checks. I think to fix this will recquire a registration
mechanism for roles acted in and headers which are understood. The roles
of NEXT and ULTIMATE_RECEIVER should always be checked I believe.
Right - this functionality has been built into Axiom since March, I
believe. The missing part is for Axis2 to have some configuration to
indicate in which roles a given service/operation plays. Then that
feeds into the call at AxisEngine.java:69.
2) Strictly speaking per the SOAP spec, I believe the conformance
requirement is that no processing occur on a message if all the
mustUnderstand headers for the appropriate roles are not understood. That
Correct. In particular, it very carefully says that it must *act as if*
no processing had occurred. In other words, as long as there are no
post-processing side effects that affect the state of the system in a
significant way, you can do whatever you want.
means, ideally, the mustUnderstand checks should be done before the
handlers are invoked, which would also require registration of roles and
understood headers. There are other issues with implenting this, though,
because of having to target the operation for example.
Again, nailed it. In Axis1 (and 2) we decided that the best way to deal
with this is a "do and rollback" approach as opposed to a "pre-flight
check". This is why it's so critical to get flowComplete() to be able
to understand if it's being called as a result of a fault or a normal
completion.... (and frankly why I'd prefer a separate revoke() method!)
3) Some of the mustUnderstand processing requirements noted above are
conformance requirements tested to some extent by the JAX-WS and JSR-181
TCKs, and 1.4 CTS (this commit only addressed part of these issues; there
are more changes which are needed to pass these tests).
+1, but can we discuss these on the list before making too many further
changes?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
