No, that's at an entirely different level.
The level I'm talking about is AXIS startup. When the chain (that will be
used in your second loop) is being built up. There will be no messages
flowing... just an environment to explore. If you have message issues,
then the handlers (that make it) in the chain must be called as they are
today (your second loop).
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Doug Davis/Raleigh/IBM@IBMUS
09/26/2002 11:05 AM
Please respond to axis-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: [axis] Smart(er) Handlers
It seems to me that you'll still need to call the handler with the
message since the determination might need the message.
So, doing:
loop over chain
call each handler to see if it wants to be invoked
loop over chain again
call each handler that wants to be called
doesn't seem any faster to me than just asking the handler
to do the "do I want to be called" check as the first thing in
its invoke() method and just looping once.
Or am I missing something?
-Dug
Richard Sitze/Austin/IBM@IBMUS on 09/26/2002 11:32:13 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: [axis] Smart(er) Handlers
Given a list of handlers to load:
H1, H2, H3
in WSDD, what I'm proposing is that the runtime query each handler as it
identifies it in a service configuration and *ask* the handler if it wants
to be loaded in the current environment:
if (handler->isEnvironmentallyFriendly())
put handler in chain...
Semantically, we can do the same thing by letting the handler (when
called) return immediately IF it doesn't have anything to do.
Why:
- I'm a performance bigot, and if the handler isn't going to *do*
anything, then I don't want it called.
- It's easy to code.
Example 1:
A Service Handler: verify that required service/classes are
(loadable) and disable handler if not.
Example 2:
Debug Handler: enable only if debug-mode ON
****
So, having put some effort into trying to give you an example (I can't
really SAY what my internal requirements are, now can I :-), it stricks me
that a reasonable and cool alternate might be:
realHandler = configuredHandler->getRealHandler();
if (realHanderl != null)
put realHandler in chain...
[names should be changed to protect the innocent..]
Default behaviour is getRealHandler() { return this; }
So, the method getRealHandler can act as a factory... a security handler
could return a 64 or 128 bit security scheme.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
