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 Tom Jordahl <tj...@adobe.com> on 2006/10/10 21:16:32 UTC
RE: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
While we may have had to work around some bugs in Thread Local Storage
(TLS) on the whole I think the Axis 1.x
MessageContext.getCurrentContext() works exceptionally well.
Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS
bugs behind us, no?
--
Tom Jordahl
Adobe ColdFusion Team
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Tuesday, October 10, 2006 10:28 AM
To: dims@apache.org
Cc: axis-dev@ws.apache.org
Subject: Re: [axis2] Improvements to Service life cycle in handling
-setOperationContext not thread-safe??!!
Other choices?
The approach we used back in ApacheSOAP was to tell the user to add an
additional first parameter to their methods if they wanted the
context .. so the signature would have an additional param and that'd
tell us to do the right thing. Very thread safe.
Need to avoid reflection - but can be done by a codegen flag. For RPC
case its reflective anyway so its not a big deal.
Sanjiva.
On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote:
> Sanjiva,
>
> We had terrible problems with TLS in Axis1...let me recollect my
> thougts and post.
>
> -- dims
>
> On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > I think I agree with you. How about we drop setOperationContext()
and
> > introduce Axis1-style MessageContext.getCurrentContext() which
returns
> > it for this thread? Have to be careful to put it in TLS and take it
off!
> >
> > We must be careful to tell users that instance variables are not
> > supported; you have to use MessageContext properties to store state
(or
> > wherever else).
> >
> > Sanjiva.
> >
> > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote:
> > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .
> > > I set the priority to blocker as David suggested.
> > >
> > > IMHO it's probably best to drop the method. Many users will use it
in an
> > > intuitive but wrong way. The only way to store the data it
provides is an
> > > instance variable, and telling users to either use only request
scope or use
> > > a ThreadLocal to store the data does not seem to be compatible
with the
> > > rule of least surprise. Something like
MessageContext.getCurrentContext()
> > > in Axis 1 might be better.
> > >
> > > Bye,
> > > Christopher.
> > >
> > > Davanum Srinivas wrote:
> > > > Chris,
> > > >
> > > > Can you please raise a new issue in JIRA?
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > > On 9/23/06, Christopher Sahnwaldt <ch...@gmx.net> wrote:
> > > >> Something worries me:
> > > >>
> > > >> > setOperationContext(OperationContext) - per call. The
messageContext
> > > >> > can be obtained to gain per call instance information.
> > > >>
> > > >> That doesn't seem to be thread-safe, does it? If I understand
this
> > > >> correctly, one service object is created per application (if
the
> > > >> service has application scope). When a request comes in, Axis
calls
> > > >> the setOperationContext method, and the service object may
store the
> > > >> OperationContext or the MessageContext. Then Axis calls the
actual
> > > >> service method, in which the service code can access the stored
> > > >> OperationContext or MessageContext. But what if two requests
come
> > > >> in almost simultaneously? The following sequence of method
calls
> > > >> may occur:
> > > >>
> > > >> - Axis calls setOperationContext with context for request A,
the
> > > >> service object stores the context in an instance field.
> > > >> - Axis calls setOperationContext with context for request B,
the same
> > > >> service object stores the context in the same instance field
and
> > > >> thus *overwrites* the context for call A.
> > > >> - Axis calls the service method with the input parameters for
request A.
> > > >> - The service method processes the call, using data from the
stored
> > > >> context, and thus *mixes the input parameters for call A with
the
> > > >> context data for call B*. Anything can happen...
> > > >> - Finally, Axis calls the service method with the input
parameters
> > > >> for call B, the service method processes the call, using data
from
> > > >> the stored context, and thus correctly uses the input
parameters
> > > >> for call B with the context data for call B. Probably ok,
unless
> > > >> the service method updated the context in some way during the
call
> > > >> for request A.
> > > >>
> > > >> But I hope I'm wrong or misunderstood or forgot something...
;-)
> > > >>
> > > >> Axis 1 avoided this problem by
MessageContext.getCurrentContext(),
> > > >> which gives access to the MessageContext *for the current
thread*
> > > >> from within any service method, without the need for a
> > > >> setMessageContext (or setOperationContext) method on the
service
> > > >> object.
> > > >>
> > > >> Bye,
> > > >> Christopher.
> > > >>
> > > >>
> > > >> Tony Dean wrote:
> > > >>
> > > >> > Can we fully document the logical semantics behind each
method?
> > > >> >
> > > >> > init(ServiceContext) - To me this use to mean application
init.
> > > >> Now it means session init. However, when running
> > > >> scope="Application", it is analogous to application init since
you
> > > >> will only have one session; but, still probably not
appropriate to
> > > >> think in those terms.
> > > >> >
> > > >> > How should an application use this method? A session
use-case
> > > >> would be nice.
> > > >> >
> > > >> > destroy(ServiceContext) - inverse of init()
> > > >> > Use-case?
> > > >> >
> > > >> > setOperationContext(OperationContext) - per call. The
> > > >> messageContext can be obtained to gain per call instance
information.
> > > >> >
> > > >> > StartUp() - one time initialization... DB connections etc...
> > > >> > Shutdown() - inverse of StartUp()
> > > >> >
> > > >> > Any more insight or corrections to pattern usage would be
grateful...
> > > >> >
> > > >> > Thanks.
> > > >> >
> > > >> > -----Original Message-----
> > > >> > From: robert lazarski [mailto:robertlazarski@gmail.com]
> > > >> > Sent: Friday, September 15, 2006 8:49 AM
> > > >> > To: axis-dev@ws.apache.org
> > > >> > Subject: Re: Improvements to Service life cycle in handling
> > > >> >
> > > >> > That makes sense to me. I've been using startUp() and it
doesn't
> > > >> really fit with the other methods of the interface in its
current
> > > >> form. +1 for 1.1 since its interface changes and it'd be better
to do
> > > >> it now.
> > > >> >
> > > >> > One question: Currently you need this in services.xml to get
> > > >> startUp() to invoke:
> > > >> >
> > > >> > <parameter name="load-on-startup"
locked="false">true</parameter>
> > > >> >
> > > >> > I plan on testing this when its ready ... since the spring
tutorial
> > > >> depends on it ... so I thought I'd ask if the services.xml
param will
> > > >> remain the same.
> > > >> >
> > > >> > Thanks,
> > > >> > Robert
> > > >> >
> > > >> > On 9/14/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
> > > >> >
> > > >> >> Hi All;
> > > >> >>
> > > >> >> Currently we have an interface called Service and which has
few
> > > >> >> methods that are used to manage session (or else user can
add those
> > > >> >> method into service impl class w.o implementing the
interface). And
> > > >> >> that interface has the following methods ;
> > > >> >>
> > > >> >> - startUp
> > > >> >> - init
> > > >> >> - setOperationContext
> > > >> >> - destroy
> > > >> >>
> > > >> >> Three of them are for managing service life cycle ;
> > > >> >> - init - will be called when the session start
> > > >> >> - setOperationContext - immediately before calling actual
java method
> > > >> >> - destroy - will be call when the session finishes
> > > >> >>
> > > >> >> Remember all those method work if and only if you use Axis2
default
> > > >> >> message receiver or you code gen.
> > > >> >>
> > > >> >> The method startUp is not session related method , which is
useful
> > > >> >> when you want to initialize database connections , create
thread etc
> > > >> >> ... at the time when you deploy the service. In the mean
time
> > > >> >> interface name Service is bit confusing to me AFAIK it
should be
> > > >> >> ServiceLifeCycle. And having method like startUp in that
interface
> > > >> confuses the users.
> > > >> >>
> > > >> >> So how about the following changes ;
> > > >> >> - Rename Service interface into ServiceLifeCycle
> > > >> >> - Then remove startUp method from that interface.
> > > >> >>
> > > >> >> There should be a some other interface (like Module
interface) and
> > > >> >> which should be optional as well , to have the method
startUp. If
> > > >> >> someone want to open DB connection or anything at the time
of service
> > > >> >> deploying , then he need to implement that interface (and
for me
> > > >> which
> > > >> >> is identical to Module interface). So with this change
service
> > > >> element
> > > >> >> inside the services.xml will be change to following
> > > >> >>
> > > >> >> <service name="foo" *class="implementation class of the
interface "*>
> > > >> >> <parameter name="ServiceClass">ServiceClass</parameter>
> > > >> >> </service>
> > > >> >>
> > > >> >> Here the class attribute is optional , so if someone want to
have
> > > >> >> loadonStartup feature then he need to implement the Service
interface
> > > >> >> (new one) and put the impl name as the class attribute. This
is very
> > > >> >> useful if your service implementation class is not java (if
you are
> > > >> >> writing a groovy serice).
> > > >> >>
> > > >> >> So new Service interface will be look like follows; public
interface
> > > >> >> Service{ //will be called when service is deployed public
void
> > > >> >> startUp(ConfigurationContext configctx, AxisService
service); //will
> > > >> >> be called when Axis2 server showdown or when service removed
from the
> > > >> >> system public void shutDown(ConfigurationContext configctx,
> > > >> >> AxisService service); }
> > > >> >>
> > > >> >> And ServiceLifeCycle interface will look like below;
> > > >> >>
> > > >> >> public interface ServiceLifeCycle {
> > > >> >> public void init(ServiceContext sc);
> > > >> >> public void setOperationContext(OperationContext
operationContext);
> > > >> >> void destroy(ServiceContext sc); }
> > > >> >>
> > > >> >>
> > > >> >> I am +1 on doing this for Axis2 1.1 :)
> > > >> >>
> > > >> >> Suggestions ........
> > > >> >>
> > > >> >> Thanks
> > > >> >> Deepal
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
---------------------------------------------------------------------
> > > >> >> 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
> > > >> >
> > > >>
> > > >>
> > > >>
---------------------------------------------------------------------
> > > >> 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
> >
> >
>
>
---------------------------------------------------------------------
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] Improvements to Service life cycle in handling -setOperationContext
not thread-safe??!!
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi
Sanjiva Weerawarana wrote:
>On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote:
>
>
>>In terms of setting up TLS info, I'm interested by the comment that it
>>would be set in the AxisEngine. When we had the conversation about the
>>ThreadContextMigrator interface (which does now exist) I understood
>>that there wasn't any guarantee that there is a single thread in use
>>through the handler chain.
>>
>>
>
>I believe it'll be set in the message receiver just before invoking the
>method right guys? I can't see why it needs to be set earlier.
>
>
Yes that was the final conclusion.
FYI:
Deepal: hi dims
[15:07] Deepal: u there
[15:08] Deepal: I dont think we can move saveTCCL(messageCtx);
in AxisEngine
[15:23] GlenD: dims?
[15:23] GlenD: u there?
[15:26] dims: ping
[15:26] GlenD: hey
[15:26] GlenD: so Deepal and I were chatting about the context stuff
[15:26] dims: yes
[15:26] GlenD: and ended up coming up with a very interesting
idea which we wanted to run past you
[15:26] dims: sure
[15:26] GlenD: I think it's too big a change for now, but it's
pretty cool for a future release
[15:27] dims: we need to make a list of those :)
[15:28] GlenD: the issue is that there's a lot of code
duplication amongst MessageReceivers
[15:28] dims: ah. that one :)
[15:28] GlenD: if we want this setTCCL stuff and the
setCurrentContext stuff to live in the MRs, it's hard to figure out
where to put it so it isn't dup'ed everywhere
[15:29] dims: call back to engine?
[15:29] dims: sorry...go ahead.
[15:29] GlenD: so we're wondering if you could maybe factor it
out into a single AbstractMessageReceiver
[15:29] GlenD: which would do the TCCL/Context stuff, then call
invokeBusinessLogic() but pass only the OperationContext
[15:29] dims: we have one of those
[15:30] dims: AbstractMessageReceiver
[15:30] GlenD: not have separate ones that pass either
(inContext) or (inContext, outContext)
[15:30] GlenD: we do?
[15:30] dims: we need to structure it better
[15:30] Deepal: we have 4 of them :)
[15:30] GlenD: right
[15:30] GlenD: we have 4
[15:30] dims: org.apache.axis2.receivers.AbstractMessageReceiver
[15:31] dims: ah. i see
[15:31] Deepal: and we are thinking of chaning
invokeBusinessLogic signature
[15:31] GlenD: only the lower level ones (AbstractInOnlyMR, etc)
actually have receive()
[15:31] GlenD: the top level one doesn't do anything
[15:31] GlenD: except hold utility methods
[15:31] dims: any cleanup is very welcome! sorely needed in this
area.
[15:31] dims: +1
[15:31] GlenD: so the interesting part is that SOMEONE needs to
know to take the outMessageContext from the operationContext and send it
[15:31] dims: please make sure you handle the spring scenario
[15:31] Deepal: invokeBusinessLogice will take OperationContext
as it argument
[15:32] GlenD: that's the real difference between in and inout
[15:32] dims: and then check isinstanceof?
[15:32] GlenD: we're wondering if there's a way to genericize
that by calling invokeBusinessLogic() and then something like complete()
or doNext()
[15:32] GlenD: but we need to think about it a little more I
think :)
[15:33] dims: yep...
[15:33] dims: pre and post?
[15:34] GlenD: (thinking here)
[15:34] dims: first step is to collapse all 4 into 1
AbstractMessageReceiver?
[15:34] dims: somehow
[15:34] GlenD: that was the thought yes but we're seeing if it
can work....
[15:35] dims: then adjust the calls to invokeBusinessLogic and
maybe call something before it and something after it for special
processing for different MEP's?
[15:36] dims: are we looking for clean code or new feature here?
[15:36] Deepal: I think both :)
[15:37] dims: and the new Feature is?..
[15:37] GlenD: its really mostly clean code
[15:37] GlenD: and a good place to put the common stuff for tls
[15:38] dims: :) ok.
[15:53] GlenD: ok never mind :)
[15:53] GlenD: I think we just came to the conclusion that it's
actually useful to have different abstract Receiver types
[15:54] GlenD: because they're the ones that know the logic for
message processing
[15:54] GlenD: if you had an in/in/out MR, for instance, it
could have processMessage1() and processMessage2() abstract operations
[15:54] GlenD: that's nicer than just relying on a single
invokeBusinessLogic(OperationContext), I think
[15:56] GlenD: So the idea is to coalesce the TCCL stuff and the
CurrentContext stuff into a setupThreadContext() and
removeThreadContext() on AbstractMessageReceiver
[15:57] GlenD: so developers of new MRs that want TLS
functionality would need to know to call that method, but it sets up
both the classloader and the MessageContext.getCurrentContext()
[16:00] dims has disconnected: Read error: 104 (Connection reset
by peer)
[16:00] dims has joined
[16:01] dims: +1 to "coalesce the TCCL stuff and the
CurrentContext stuff into a setupThreadContext() and removeThreadContext()"
[16:01] GlenD: great
[16:01] Deepal: +1 for doing that for 1.1
[16:01] dims: sure
[16:02] dims: but again. proposal to mailing list.
[16:07] GlenD: ya
[16:35] GlenD: brb
[16:35] GlenD has disconnected
[16:36] GlenD has joined
[17:13] Deepal: this time hackerthon seems good to me
[17:14] Deepal: finding bugs , improvements
[17:14] Deepal: s/hackerthon/hackarthon
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
Posted by David Illsley <da...@gmail.com>.
On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote:
> > In terms of setting up TLS info, I'm interested by the comment that it
> > would be set in the AxisEngine. When we had the conversation about the
> > ThreadContextMigrator interface (which does now exist) I understood
> > that there wasn't any guarantee that there is a single thread in use
> > through the handler chain.
>
> I believe it'll be set in the message receiver just before invoking the
> method right guys? I can't see why it needs to be set earlier.
>
I agree it doesn't need to be earlier.
>From Deepal earlier in this thread:
Deepal41: hi dims
[12:06] GlenD: [11:59] <GlenD> so we're now talking about
setting a TLS OperationContext.getCurrentContext() into the AxisEngine,
right before it calls the MessageReceiver
[12:06] GlenD: [11:59] <GlenD> and putting the thread
ClassLoader stuff right in the same place
[12:06] GlenD: [11:59] <GlenD> so it's factored out of the
individual MRs
[12:06] dims: +1
[12:07] ruchith: +1
[12:07] ruchith: we don't have to duplicate code this way
[12:07] Deepal41: in the mean time shall we move
...
David
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Improvements to Service life cycle in handling
-setOperationContext not thread-safe??!!
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2006-10-10 at 20:21 +0100, David Illsley wrote:
> In terms of setting up TLS info, I'm interested by the comment that it
> would be set in the AxisEngine. When we had the conversation about the
> ThreadContextMigrator interface (which does now exist) I understood
> that there wasn't any guarantee that there is a single thread in use
> through the handler chain.
I believe it'll be set in the message receiver just before invoking the
method right guys? I can't see why it needs to be set earlier.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Improvements to Service life cycle in handling -setOperationContext not thread-safe??!!
Posted by David Illsley <da...@gmail.com>.
In terms of setting up TLS info, I'm interested by the comment that it
would be set in the AxisEngine. When we had the conversation about the
ThreadContextMigrator interface (which does now exist) I understood
that there wasn't any guarantee that there is a single thread in use
through the handler chain.
Was this a misunderstanding or is this a change?
David
On 10/10/06, Tom Jordahl <tj...@adobe.com> wrote:
>
> While we may have had to work around some bugs in Thread Local Storage
> (TLS) on the whole I think the Axis 1.x
> MessageContext.getCurrentContext() works exceptionally well.
>
> Since JDK 1.4 is the minimum for Axis2, I believe we have all the TLS
> bugs behind us, no?
>
>
> --
> Tom Jordahl
> Adobe ColdFusion Team
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Tuesday, October 10, 2006 10:28 AM
> To: dims@apache.org
> Cc: axis-dev@ws.apache.org
> Subject: Re: [axis2] Improvements to Service life cycle in handling
> -setOperationContext not thread-safe??!!
>
> Other choices?
>
> The approach we used back in ApacheSOAP was to tell the user to add an
> additional first parameter to their methods if they wanted the
> context .. so the signature would have an additional param and that'd
> tell us to do the right thing. Very thread safe.
>
> Need to avoid reflection - but can be done by a codegen flag. For RPC
> case its reflective anyway so its not a big deal.
>
> Sanjiva.
>
> On Tue, 2006-10-10 at 09:40 -0400, Davanum Srinivas wrote:
> > Sanjiva,
> >
> > We had terrible problems with TLS in Axis1...let me recollect my
> > thougts and post.
> >
> > -- dims
> >
> > On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > > I think I agree with you. How about we drop setOperationContext()
> and
> > > introduce Axis1-style MessageContext.getCurrentContext() which
> returns
> > > it for this thread? Have to be careful to put it in TLS and take it
> off!
> > >
> > > We must be careful to tell users that instance variables are not
> > > supported; you have to use MessageContext properties to store state
> (or
> > > wherever else).
> > >
> > > Sanjiva.
> > >
> > > On Sun, 2006-09-24 at 14:12 +0200, Christopher Sahnwaldt wrote:
> > > > Entered as http://issues.apache.org/jira/browse/AXIS2-1224 .
> > > > I set the priority to blocker as David suggested.
> > > >
> > > > IMHO it's probably best to drop the method. Many users will use it
> in an
> > > > intuitive but wrong way. The only way to store the data it
> provides is an
> > > > instance variable, and telling users to either use only request
> scope or use
> > > > a ThreadLocal to store the data does not seem to be compatible
> with the
> > > > rule of least surprise. Something like
> MessageContext.getCurrentContext()
> > > > in Axis 1 might be better.
> > > >
> > > > Bye,
> > > > Christopher.
> > > >
> > > > Davanum Srinivas wrote:
> > > > > Chris,
> > > > >
> > > > > Can you please raise a new issue in JIRA?
> > > > >
> > > > > thanks,
> > > > > dims
> > > > >
> > > > > On 9/23/06, Christopher Sahnwaldt <ch...@gmx.net> wrote:
> > > > >> Something worries me:
> > > > >>
> > > > >> > setOperationContext(OperationContext) - per call. The
> messageContext
> > > > >> > can be obtained to gain per call instance information.
> > > > >>
> > > > >> That doesn't seem to be thread-safe, does it? If I understand
> this
> > > > >> correctly, one service object is created per application (if
> the
> > > > >> service has application scope). When a request comes in, Axis
> calls
> > > > >> the setOperationContext method, and the service object may
> store the
> > > > >> OperationContext or the MessageContext. Then Axis calls the
> actual
> > > > >> service method, in which the service code can access the stored
> > > > >> OperationContext or MessageContext. But what if two requests
> come
> > > > >> in almost simultaneously? The following sequence of method
> calls
> > > > >> may occur:
> > > > >>
> > > > >> - Axis calls setOperationContext with context for request A,
> the
> > > > >> service object stores the context in an instance field.
> > > > >> - Axis calls setOperationContext with context for request B,
> the same
> > > > >> service object stores the context in the same instance field
> and
> > > > >> thus *overwrites* the context for call A.
> > > > >> - Axis calls the service method with the input parameters for
> request A.
> > > > >> - The service method processes the call, using data from the
> stored
> > > > >> context, and thus *mixes the input parameters for call A with
> the
> > > > >> context data for call B*. Anything can happen...
> > > > >> - Finally, Axis calls the service method with the input
> parameters
> > > > >> for call B, the service method processes the call, using data
> from
> > > > >> the stored context, and thus correctly uses the input
> parameters
> > > > >> for call B with the context data for call B. Probably ok,
> unless
> > > > >> the service method updated the context in some way during the
> call
> > > > >> for request A.
> > > > >>
> > > > >> But I hope I'm wrong or misunderstood or forgot something...
> ;-)
> > > > >>
> > > > >> Axis 1 avoided this problem by
> MessageContext.getCurrentContext(),
> > > > >> which gives access to the MessageContext *for the current
> thread*
> > > > >> from within any service method, without the need for a
> > > > >> setMessageContext (or setOperationContext) method on the
> service
> > > > >> object.
> > > > >>
> > > > >> Bye,
> > > > >> Christopher.
> > > > >>
> > > > >>
> > > > >> Tony Dean wrote:
> > > > >>
> > > > >> > Can we fully document the logical semantics behind each
> method?
> > > > >> >
> > > > >> > init(ServiceContext) - To me this use to mean application
> init.
> > > > >> Now it means session init. However, when running
> > > > >> scope="Application", it is analogous to application init since
> you
> > > > >> will only have one session; but, still probably not
> appropriate to
> > > > >> think in those terms.
> > > > >> >
> > > > >> > How should an application use this method? A session
> use-case
> > > > >> would be nice.
> > > > >> >
> > > > >> > destroy(ServiceContext) - inverse of init()
> > > > >> > Use-case?
> > > > >> >
> > > > >> > setOperationContext(OperationContext) - per call. The
> > > > >> messageContext can be obtained to gain per call instance
> information.
> > > > >> >
> > > > >> > StartUp() - one time initialization... DB connections etc...
> > > > >> > Shutdown() - inverse of StartUp()
> > > > >> >
> > > > >> > Any more insight or corrections to pattern usage would be
> grateful...
> > > > >> >
> > > > >> > Thanks.
> > > > >> >
> > > > >> > -----Original Message-----
> > > > >> > From: robert lazarski [mailto:robertlazarski@gmail.com]
> > > > >> > Sent: Friday, September 15, 2006 8:49 AM
> > > > >> > To: axis-dev@ws.apache.org
> > > > >> > Subject: Re: Improvements to Service life cycle in handling
> > > > >> >
> > > > >> > That makes sense to me. I've been using startUp() and it
> doesn't
> > > > >> really fit with the other methods of the interface in its
> current
> > > > >> form. +1 for 1.1 since its interface changes and it'd be better
> to do
> > > > >> it now.
> > > > >> >
> > > > >> > One question: Currently you need this in services.xml to get
> > > > >> startUp() to invoke:
> > > > >> >
> > > > >> > <parameter name="load-on-startup"
> locked="false">true</parameter>
> > > > >> >
> > > > >> > I plan on testing this when its ready ... since the spring
> tutorial
> > > > >> depends on it ... so I thought I'd ask if the services.xml
> param will
> > > > >> remain the same.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Robert
> > > > >> >
> > > > >> > On 9/14/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
> > > > >> >
> > > > >> >> Hi All;
> > > > >> >>
> > > > >> >> Currently we have an interface called Service and which has
> few
> > > > >> >> methods that are used to manage session (or else user can
> add those
> > > > >> >> method into service impl class w.o implementing the
> interface). And
> > > > >> >> that interface has the following methods ;
> > > > >> >>
> > > > >> >> - startUp
> > > > >> >> - init
> > > > >> >> - setOperationContext
> > > > >> >> - destroy
> > > > >> >>
> > > > >> >> Three of them are for managing service life cycle ;
> > > > >> >> - init - will be called when the session start
> > > > >> >> - setOperationContext - immediately before calling actual
> java method
> > > > >> >> - destroy - will be call when the session finishes
> > > > >> >>
> > > > >> >> Remember all those method work if and only if you use Axis2
> default
> > > > >> >> message receiver or you code gen.
> > > > >> >>
> > > > >> >> The method startUp is not session related method , which is
> useful
> > > > >> >> when you want to initialize database connections , create
> thread etc
> > > > >> >> ... at the time when you deploy the service. In the mean
> time
> > > > >> >> interface name Service is bit confusing to me AFAIK it
> should be
> > > > >> >> ServiceLifeCycle. And having method like startUp in that
> interface
> > > > >> confuses the users.
> > > > >> >>
> > > > >> >> So how about the following changes ;
> > > > >> >> - Rename Service interface into ServiceLifeCycle
> > > > >> >> - Then remove startUp method from that interface.
> > > > >> >>
> > > > >> >> There should be a some other interface (like Module
> interface) and
> > > > >> >> which should be optional as well , to have the method
> startUp. If
> > > > >> >> someone want to open DB connection or anything at the time
> of service
> > > > >> >> deploying , then he need to implement that interface (and
> for me
> > > > >> which
> > > > >> >> is identical to Module interface). So with this change
> service
> > > > >> element
> > > > >> >> inside the services.xml will be change to following
> > > > >> >>
> > > > >> >> <service name="foo" *class="implementation class of the
> interface "*>
> > > > >> >> <parameter name="ServiceClass">ServiceClass</parameter>
> > > > >> >> </service>
> > > > >> >>
> > > > >> >> Here the class attribute is optional , so if someone want to
> have
> > > > >> >> loadonStartup feature then he need to implement the Service
> interface
> > > > >> >> (new one) and put the impl name as the class attribute. This
> is very
> > > > >> >> useful if your service implementation class is not java (if
> you are
> > > > >> >> writing a groovy serice).
> > > > >> >>
> > > > >> >> So new Service interface will be look like follows; public
> interface
> > > > >> >> Service{ //will be called when service is deployed public
> void
> > > > >> >> startUp(ConfigurationContext configctx, AxisService
> service); //will
> > > > >> >> be called when Axis2 server showdown or when service removed
> from the
> > > > >> >> system public void shutDown(ConfigurationContext configctx,
> > > > >> >> AxisService service); }
> > > > >> >>
> > > > >> >> And ServiceLifeCycle interface will look like below;
> > > > >> >>
> > > > >> >> public interface ServiceLifeCycle {
> > > > >> >> public void init(ServiceContext sc);
> > > > >> >> public void setOperationContext(OperationContext
> operationContext);
> > > > >> >> void destroy(ServiceContext sc); }
> > > > >> >>
> > > > >> >>
> > > > >> >> I am +1 on doing this for Axis2 1.1 :)
> > > > >> >>
> > > > >> >> Suggestions ........
> > > > >> >>
> > > > >> >> Thanks
> > > > >> >> Deepal
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> ---------------------------------------------------------------------
> > > > >> >> 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
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> 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
> > >
> > >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org