> > 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.
Yeah, I dunno either, though I'm leaning towards doing it. I'd like to ponder it for a little longer. Meanwhile, do any other handler writers have an opinion? This doesn't modify the interface in any way, and gives them role support for free... > > 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. Glad to hear this has an easy answer :-) David -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
