Hi David:
I'm sympathetic to the argument of getting into the habit of doing the
right thing, but what you're suggesting means we'll repeatedly do role
processing for all headers in every handler which doesn't seem
optimal.
I think it works out to pretty much a wash. The way we do it now, which
is each handler scanning the headers for what it's interested in (by
namespace) and then checking that subset for roles (which only happens
for addressing right now, ugh) ends up being almost the exact same work,
just done in a slightly different order. If there are a LOT of headers
targeted at us which don't match - or a lot of headers in our namespace
which aren't targeted at us, we could end up wasting a little time,
which is why a getHeadersToProcess(rolePlayer, namespace) might be good
as it would cycle through only once. But I'm guessing the difference
isn't that critical in most cases.
So... we could* add a useRolePlayer(RolePlayer rp) to the SOAPHeader
which would cause all the existing methods to use a once-computed
subset of the headers until useRolePlayer() is called again (possibly
with null). Axis2 would set it by default before the handler chain.
Yep, I'd had that exact same thought while doing the role processing
stuff in Axiom. :) The only issue I had was whether it was right to
make the SOAPHeader that "stateful"... but in thinking about it a little
more I think it's fine, since we're never really going to be passing it
around outside one node. (speaking of node, we should also be
supporting the SOAP 1.2 node attribute....)
Plus to this approach - all accessors automatically respect roles.
Minus - we have to do the subsetting/filtering each time we have a role
change... so for instance if a Module wanted to use its own role, we'd
need to add that one somehow.
I dunno, I think we might want to go for it.
The only problem I forsee with that I don't know how it would work
with ws-sec (where presumably the role could be encrypted to begin
with?)
If Rampart decrypts a header, it needs to start the processing model
again, at least for that header. See section 9.4.5 of [1]. So for
this, we'd either rebuild or just add to the stored subset as necessary.
--Glen
[1]
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
