Hi Sanjiva,
Logically, you can think of them as an extension to the handler
mechanism that runs at the border between the core Axis2 code and the
programming model layer (e.g. in the JAX-WS case they'll be run inside
of the JAXWSMessageReceiver, the jaxws...AxisInvocationController, and
the jaxws...AxisCallback (I believe.)) They're really just a set of
utility methods that get invoked to bridge between the Axis2 context
model and the external programming model that is exposed to the end
user, so they don't have a lifecycle per say. I specifically haven't
tied the registration of the migrators (I'm happy for a different name
8-]) to a handler or module, as (1) they are programming model specific,
while the modules/handlers deal with the Axis2 model and (2) on the
sender side, the modules may not have been engaged by the time that this
code needs to execute. Implementation of the migrators falls somewhere
between the responsibility of the programming model implementor and the
QoS implementor -- as I said, it's really bridging code.
I will try to send out the diffs of my code later today after I get the
changes put into the new JAX-WS code.
-Bill
On Wed, 2006-07-12 at 22:12 +0530, Sanjiva Weerawarana wrote:
> On Wed, 2006-07-12 at 09:40 -0400, Bill Nagy wrote:
> > Hi dims,
> >
> > Sure. You are correct, there is no TLS code currently in Axis2.
> > However we (IBM) have several cases (e.g. security) where we need to
> > migrate information between the Axis2 contexts and TLS. For example, we
> > have identity APIs that rely upon tokens being placed in TLS. While we
> > can have the handler place the information in the MessageContext for
> > example, we need to move it to TLS before we enter "user space," so that
> > if the user invokes one of our security APIs the information will be
> > available. (We also need to make sure that the info is removed from TLS
> > when we're done, hence the flowComplete() method.)
>
> So is this basically a utility class that a specific handler invokes? Or
> are you suggesting that people register these "migrators" against a
> handler and then they get invoked upon entry/exit? I guess the lifecycle
> and programming model for TCMigrators is not clear enough to me yet!
>
> Sanjiva.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
