This took a little longer than I would have liked, but I've opened a JIRA issue (Axis2-938) and attached my patch. Comments are welcome.
-Bill On Wed, 2006-07-12 at 14:20 -0400, Bill Nagy wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
