> > Restructuring is fine by me - I know it's necessary. Add that method > > by all means, but given recent experience of writing handlers, I don't > > think we can add methods for all the useful header access patterns > > people might want. > > Yup, understood. We should look carefully at the ones that are there > and figure out what the right baseline set is. > > > Given that, how about we also add (I'm not bothered about the exact name): > > SOAPHeaderBlock.matchesRole(RolePlayer rp) > > You mean like "Iterator getHeadersToProcess(RolePlayer rolePlayer)"? :)
Sort of :-) What I'd like to be able to do is to check a SOAPHeaderBlock against a RolePlayer in isolation, rather than exclusively by using an accessor on SOAPHeader. I'm really thinking in terms of performance, and not doing work we don't need to do. We don't need to check the role/actor on uninteresting headers and we want to enable people to write handlers which process each header only once (or at least I do :-). So when my handler is running I'd like to only do the work to check the role for header blocks I might be interested in. e.g. in org.apache.sandesha2.wsrm.RMElements.processHeaders() [1] I'd like to simply check the roles on headers which pass the check: if(isSPEC2005_02 || isSPEC2007_02) Given how widely used the role/actor attributes are, I believe this is the right way round. Seem reasonable? David [1] http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/wsrm/RMElements.java?revision=593299&view=markup -- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
