You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Bill Nagy <na...@watson.ibm.com> on 2006/07/12 15:40:42 UTC
Re: [Axis2] Plugpoint to allow for migration between context and
TLS
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 given the above example, our security code would include something
like:
public class SampleMigrator implements ThreadContextMigrator
{
void migrateContext(MessageContext messageContext) throws AxisFault
{
Object identityToken = messageContext.getProperty("identityToken");
SecurityCode.placeOnTLS(identityToken);
}
void flowComplete(MessageContext messageContext)
{
SecurityCode.removeFromTLS();
}
}
that the handler (or something else) would register, and then the JAX-WS
(or SCA or whatever) code would invoke when execution was running on the
ultimate thread.
Does that make sense?
-Bill
On Wed, 2006-07-12 at 09:15 -0400, Davanum Srinivas wrote:
> Bill,
>
> Could you please flesh out a test case as well to show how the new
> interface should be used? I still can't figure out in my head..I don't
> remember seeing any TLS code in the current Axis2 svn. Am i missing
> something?
>
> thanks,
> dims
>
> On 7/12/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > Hi folks,
> >
> > As I mentioned in one of my notes a while ago, we have an issue with
> > some APIs (e.g. security, Tx) requiring that data be present on Thread
> > Local Storage (TLS). I believe that we can work around (at least for
> > now) needing to migrate information between threads, and can simply get
> > away with storing it in one of the contexts and then moving it to TLS
> > before we get into user space (i.e. up through the service programming
> > model) and then back again if need be.
> >
> > Unless there are objections, I'm going to create a new Interface,
> > org.apache.axis2.util.ThreadContextMigrator, with two methods, void
> > migrateContext(MessageContext messageContext) and void flowComplete
> > (MessageContext messageContext), add a List and accessor methods to the
> > AxisConfiguration to store instances of the Interface, and add the
> > appropriate invocations in the JAX-WS code to invoke them. (If there
> > are no registered instances, then the only cost is checking to see if
> > the List is empty.)
> >
> > The second method is needed to allow for cleanup of the TLS after
> > execution has completed.
> >
> > Questions/comments?
> >
> > -Bill
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Plugpoint to allow for migration between context and TLS
Posted by Davanum Srinivas <da...@gmail.com>.
makes sense :)
next question, where does migrateContext and flowComplete get called
from? do you have an idea? (any diffs i can review?)
thx,
dims
On 7/12/06, Bill Nagy <na...@watson.ibm.com> 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 given the above example, our security code would include something
> like:
>
> public class SampleMigrator implements ThreadContextMigrator
> {
> void migrateContext(MessageContext messageContext) throws AxisFault
> {
> Object identityToken = messageContext.getProperty("identityToken");
> SecurityCode.placeOnTLS(identityToken);
> }
>
> void flowComplete(MessageContext messageContext)
> {
> SecurityCode.removeFromTLS();
> }
> }
>
> that the handler (or something else) would register, and then the JAX-WS
> (or SCA or whatever) code would invoke when execution was running on the
> ultimate thread.
>
> Does that make sense?
>
> -Bill
>
>
> On Wed, 2006-07-12 at 09:15 -0400, Davanum Srinivas wrote:
> > Bill,
> >
> > Could you please flesh out a test case as well to show how the new
> > interface should be used? I still can't figure out in my head..I don't
> > remember seeing any TLS code in the current Axis2 svn. Am i missing
> > something?
> >
> > thanks,
> > dims
> >
> > On 7/12/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > > Hi folks,
> > >
> > > As I mentioned in one of my notes a while ago, we have an issue with
> > > some APIs (e.g. security, Tx) requiring that data be present on Thread
> > > Local Storage (TLS). I believe that we can work around (at least for
> > > now) needing to migrate information between threads, and can simply get
> > > away with storing it in one of the contexts and then moving it to TLS
> > > before we get into user space (i.e. up through the service programming
> > > model) and then back again if need be.
> > >
> > > Unless there are objections, I'm going to create a new Interface,
> > > org.apache.axis2.util.ThreadContextMigrator, with two methods, void
> > > migrateContext(MessageContext messageContext) and void flowComplete
> > > (MessageContext messageContext), add a List and accessor methods to the
> > > AxisConfiguration to store instances of the Interface, and add the
> > > appropriate invocations in the JAX-WS code to invoke them. (If there
> > > are no registered instances, then the only cost is checking to see if
> > > the List is empty.)
> > >
> > > The second method is needed to allow for cleanup of the TLS after
> > > execution has completed.
> > >
> > > Questions/comments?
> > >
> > > -Bill
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Plugpoint to allow for migration between context and
TLS
Posted by Bill Nagy <na...@watson.ibm.com>.
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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Plugpoint to allow for migration between context and
TLS
Posted by Bill Nagy <na...@watson.ibm.com>.
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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Plugpoint to allow for migration between context and
TLS
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org