-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
indeed the order of header blocks does not matter at all in axis2 (and afaik most other soap processors). But what I want to do is to define an order in some way for every single message (that is order may differ between messages) and enforce that defined order on the header processing. Unfortunately the required order of header processing is _not_ known at configuration time so the configuration of handler chains and the execution order of the handlers within a chain can not be configured statically in axis2.xml but have to change from one message to another. My question is: Is it possible in axis2 to change the order of handlers for a single message at runtime? That is: one message goes to logging, then to security, then addressing while another one goes to security then logging etc. How can I achieve that? Meaning: where do I have to look? Any ideas? Thanks in advance, Fred. Ajith Ranabahu schrieb: > Hi, > AFAIK the order of the header blocks inside the message does not > matter for Axis2. It is the order of handlers that controls the header > block processing order. For example if the security handler comes > before the addressing handler, security will be processed first > regardless of the header block order inside the message. > A possible way of enforcing a particular header processing order would > be a dynamic arrangement of handlers inside the handler chain, > probably by another handler sitting in the early phases of the chain. > However there are certain handler combinations that are not at all > recommended to mess with, such as the security/addressing/dispatching > handlers. > > HTH > > Ajith > > > On 6/28/06, Frederik Juchart <[EMAIL PROTECTED]> wrote: > Hi, > > I'm currently working on my diploma thesis "developing a routing > mechanism for > soap messages". In addition to "simply" routing the message from one > node to > another I have to dynamically (depending on the routing) define the > sequence in > which soap headers are processed. > > Example: someone sends a soap message and wants that message to be > routed to a > logging service, a signature service and an encryption service in > exactly that > order. These services are addressed via distinct soap headers. There > wouldn't > be a problem if each soap node could only understand one of those > headers... but... > If one soap node was able to process all of those headers I would have > to make > sure that the headers are executed in the correct order. > > I know that soap standard does not define a sequence on headers, but > it says > "The processing of one or more SOAP header blocks MAY control or > determine the > order of processing for other SOAP header blocks and/or the SOAP body. > For > example, one could create a SOAP header block to force processing of > other SOAP > header blocks in lexical order." - which is what I want to do, though > I wont > use lexical order, of course ;) > > I am currently trying to implement a mechanism to define the processing > sequence of soap headers. > As I want the routing/sequence of headers to be defined within the > message (as > a soap header) I would have to be able to change the sequence in which > handlers > are executed in axis2 _at runtime_ from within a handler... > > Is it possible to change the sequence of header processing for the > current > message from within a handler? If so... could you give me a hint on > where to look? > Or do I have to do it differently? > Or is this impossible with axis2? *yikes* > > Sorry for bothering you with my question but I did not know where else > to look... > > > Thank you very much in advance, > > > Frederik Juchart >> - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) iD8DBQFEoowFmWG8h1lbW+URAl90AJ4iZl/lfjsBnH/1RxtNLX3tvOF8vwCeOcZ4 0j0P5ckSPkjmWZh6Dt6da2g= =D2tF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
