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 robert lazarski <ro...@gmail.com> on 2006/09/15 14:48:37 UTC
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
Re: Improvements to Service life cycle in handling
Posted by Rajith Attapattu <ra...@gmail.com>.
Robert,
How is this going to affect the spring stuff.
Especially how is this going to affect the way the appContext.xml is loaded?
Regards,
Rajith
On 9/15/06, robert lazarski <ro...@gmail.com> wrote:
>
> 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
>
>
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Posted by David Illsley <da...@gmail.com>.
IMO this should be a blocker for 1.1
David
On 24/09/06, Davanum Srinivas <da...@gmail.com> 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
> >
> >
>
>
> --
> 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
>
>
--
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 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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext
not thread-safe??!!
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Deepal,
>> Deploying a service in application scope , user want to have once
>> service impl instance (im I were a user , I want that )
>
>
> Frankly I don't...
:)
> Service impl class is a Axis2 bundled MR(eg:
> RawXMLInOut..) specific notion... Service impl is meaning less if the
> user has written a custom MR..
yes , I agree.
btw we use all those concept in code gen as well , I mean all the
generated MR support all those.
> One example would be a BPELEngine
> (which I did :) ), where we had our own Message Receiver and we stored
> all the state data in the service context..
yes , as I told you earlier thats the perfect way , but there are users
how want to store values in service impl.
(And for me I think that is not that bad when you deploy a service in
application scope)
> See
> http://issues.apache.org/jira/browse/AXIS2-1133 this too..
>
>> so we're now talking about
>> setting a TLS OperationContext.getCurrentContext() into the AxisEngine,
>> right before it calls the MessageReceiver
>
>
> I'm not sure about the impact of this change... If this is not a
> straight forward change I doubt whether we should do this at this
> moment... Don't want to take any chances towards 1.1 :(...
no , if we are going to make this change we have to do that before 1.1 ,
and I dont think the change we are planing to do will affect that much :)
>
>> We should maintain both ,I mean
>> - should have only one serviceContext
>> - and only one service impl
>
>
> any concrete use cases.... Use cases which cannot be implemented using
> by storing the state data in the service context...
>
>
>> What if user want to keep local variable inside the impl class . I know
>> that is not the best practice bt ppl are using that .
>
> Then why we gonna encourage that ??
>
> Thanks,
> ~Thilina
>
>>
>> > IMO anybody can use
>> > the ServiceContext to store whatever the state data needed to be
>> > shared across the life of the service...Are there any special cases
>> > where we can't do that.. If there aren't any reasons my suggestion is
>> > to create the service object per invocation.
>> >
>> > Also a user who uses the application scope might most probably be
>> > working in the messagereceiver(MR) level, since MR is known to be the
>> > ultimate message recipient in Axis2. One possible example is a BPEL
>> > engine.. In that case the concept of one service object for the life
>> > time of the service invalidates.. AFAIKS AXIS2-1133 is another
>> > implication of this design...
>> >
>> > Thanks,
>> > Thilina
>> >
>> > On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>> >
>> >> 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
>> >>
>> >>
>> >
>> >
>>
>> --
>> Thanks,
>> Deepal
>> ................................................................
>> ~Future is Open~
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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 Rajith Attapattu <ra...@gmail.com>.
Thilina,
I understand your use case about having to create a new object for each
invocation.
But your use case is clearly in the minority. (meaning people will not do
that often)
So if you have a special requirment like that then why not use the concept
of "ServiceObjectSupplier".
So if u specify a custom service object supplier which creates a new service
object irrespective of the scope then you are fine.
We should not in my opinion change the general expectation of the users at
large to implement special cases.
As a user my understanding of "Application Scope" is that I have a Service
that will live for the life of the application.
And I may have (or choose to do so) instance variables that I maybe relying
across multiple invocations.
I may also want to init "expensive" resources in my init().
All these assumptions which are based on the general idea about "application
scope" are no longer valid if choose to create new objects each time.
Regards,
Rajith
On 10/10/06, Thilina Gunarathne <cs...@gmail.com> wrote:
>
> Hi Deepal,
> >Deploying a service in application scope , user want to have once
> >service impl instance (im I were a user , I want that )
>
> Frankly I don't... Service impl class is a Axis2 bundled MR(eg:
> RawXMLInOut..) specific notion... Service impl is meaning less if the
> user has written a custom MR.. One example would be a BPELEngine
> (which I did :) ), where we had our own Message Receiver and we stored
> all the state data in the service context.. See
> http://issues.apache.org/jira/browse/AXIS2-1133 this too..
>
> >so we're now talking about
> > setting a TLS OperationContext.getCurrentContext() into the AxisEngine,
> > right before it calls the MessageReceiver
>
> I'm not sure about the impact of this change... If this is not a
> straight forward change I doubt whether we should do this at this
> moment... Don't want to take any chances towards 1.1 :(...
>
> > We should maintain both ,I mean
> > - should have only one serviceContext
> > - and only one service impl
>
> any concrete use cases.... Use cases which cannot be implemented using
> by storing the state data in the service context...
>
>
> > What if user want to keep local variable inside the impl class . I know
> > that is not the best practice bt ppl are using that .
> Then why we gonna encourage that ??
>
> Thanks,
> ~Thilina
>
> >
> > > IMO anybody can use
> > > the ServiceContext to store whatever the state data needed to be
> > > shared across the life of the service...Are there any special cases
> > > where we can't do that.. If there aren't any reasons my suggestion is
> > > to create the service object per invocation.
> > >
> > > Also a user who uses the application scope might most probably be
> > > working in the messagereceiver(MR) level, since MR is known to be the
> > > ultimate message recipient in Axis2. One possible example is a BPEL
> > > engine.. In that case the concept of one service object for the life
> > > time of the service invalidates.. AFAIKS AXIS2-1133 is another
> > > implication of this design...
> > >
> > > Thanks,
> > > Thilina
> > >
> > > On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > >
> > >> 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
> > >>
> > >>
> > >
> > >
> >
> > --
> > Thanks,
> > Deepal
> > ................................................................
> > ~Future is Open~
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> http://webservices.apache.org/~thilina/
> http://thilinag.blogspot.com/
>
> ---------------------------------------------------------------------
> 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 Thilina Gunarathne <cs...@gmail.com>.
Hi Deepal,
>Deploying a service in application scope , user want to have once
>service impl instance (im I were a user , I want that )
Frankly I don't... Service impl class is a Axis2 bundled MR(eg:
RawXMLInOut..) specific notion... Service impl is meaning less if the
user has written a custom MR.. One example would be a BPELEngine
(which I did :) ), where we had our own Message Receiver and we stored
all the state data in the service context.. See
http://issues.apache.org/jira/browse/AXIS2-1133 this too..
>so we're now talking about
> setting a TLS OperationContext.getCurrentContext() into the AxisEngine,
> right before it calls the MessageReceiver
I'm not sure about the impact of this change... If this is not a
straight forward change I doubt whether we should do this at this
moment... Don't want to take any chances towards 1.1 :(...
> We should maintain both ,I mean
> - should have only one serviceContext
> - and only one service impl
any concrete use cases.... Use cases which cannot be implemented using
by storing the state data in the service context...
> What if user want to keep local variable inside the impl class . I know
> that is not the best practice bt ppl are using that .
Then why we gonna encourage that ??
Thanks,
~Thilina
>
> > IMO anybody can use
> > the ServiceContext to store whatever the state data needed to be
> > shared across the life of the service...Are there any special cases
> > where we can't do that.. If there aren't any reasons my suggestion is
> > to create the service object per invocation.
> >
> > Also a user who uses the application scope might most probably be
> > working in the messagereceiver(MR) level, since MR is known to be the
> > ultimate message recipient in Axis2. One possible example is a BPEL
> > engine.. In that case the concept of one service object for the life
> > time of the service invalidates.. AFAIKS AXIS2-1133 is another
> > implication of this design...
> >
> > Thanks,
> > Thilina
> >
> > On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> >
> >> 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
> >>
> >>
> >
> >
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
---------------------------------------------------------------------
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 Thilina
Thilina Gunarathne wrote:
> Ok... Here's my suggestion.. Let's create new service objects per
> invocation..
I do not agree with this approach :) , with this if some one deploy a
service with application scope then there will be multiple instance of
same service impl class.
Deploying a service in application scope , user want to have once
service impl instance (im I were a user , I want that )
btw : there was a JIRA issues on this couple of month ago.
Here in ApacheCon US , we are discussed abt the this issue deeper ,and
we agreed to use Sanjiva's suggestion. MessageContext.getCurrentContext().
P.S :
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
saveTCCL(messageCtx);
[12:07] Deepal41: into AxisEnine too
[12:07] Deepal41: what do u think dims ?
[12:07] dims: ok
[12:08] dims: sounds good
[12:08] dims: need to get Ali to test his ejb stuff and get
Robert to test spring support again after that change
[12:09] GlenD: +1
[12:09] sanka has joined
[12:10] Deepal41: +1
[12:12] Deepal41: one more q
[12:13] Deepal41: is that OperationContext.getCurrentConetct();
[12:13] GlenD: getCurrentContext()
[12:13] Deepal41: or MessageContext..getCurrentContext();
[12:14] GlenD: Personally, I prefer MC.getCurrentContext()
[12:14] GlenD: but I'm fine with OC.getCurrentContext() too
[12:14] Deepal41: how abt others
[12:14] dims: Let's write it up and post to the list (with both
options)
[12:14] GlenD: I just think you don't lose anything by doing it
in the MC, and it allows you to get the current MC properties without
having to know which one to ask for from the OC
[12:14] GlenD: sure, dims
[12:15] Deepal41: ok , then let's go with MC.getCurrentContext();
[12:15] dims: was just reading email from incubator folks about
not taking decisions on the irc :)
[12:15] Deepal41: :)
[12:16] Deepal41: hmm , I am +1 on MC.getCurrentContext();
[12:17] GlenD: hee hee
[12:17] GlenD: we were just talking about IRC vs email a bit ago
[12:17] dims: guys read the email from thilina as well
[12:17] GlenD: k
>
> AFAIK two things happen when we deploy a service in application scope.
> One is that Axis2 will maintain a single service context throughout
> the life of the service.. Other thing is Axis2 maintains one service
> class object throughout the life of the service, serving for all the
> requests..
We should maintain both ,I mean
- should have only one serviceContext
- and only one service impl
> Maintaining of the service context is really important and useful..
> Users can use it to store whatever the state data that needs to shared
> throughout the life of the service. IIRC this is one of the use cases
> we came up with for the Axis2 context hierarchy- to make the engine
> stateless..
Totallly agrred.
>
> On the other hand, i don't see any reason for maintaining a single
> service object throughout the life of the service.
What if user want to keep local variable inside the impl class . I know
that is not the best practice bt ppl are using that .
> IMO anybody can use
> the ServiceContext to store whatever the state data needed to be
> shared across the life of the service...Are there any special cases
> where we can't do that.. If there aren't any reasons my suggestion is
> to create the service object per invocation.
>
> Also a user who uses the application scope might most probably be
> working in the messagereceiver(MR) level, since MR is known to be the
> ultimate message recipient in Axis2. One possible example is a BPEL
> engine.. In that case the concept of one service object for the life
> time of the service invalidates.. AFAIKS AXIS2-1133 is another
> implication of this design...
>
> Thanks,
> Thilina
>
> On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
>> 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
>>
>>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
---------------------------------------------------------------------
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 Rajith Attapattu <ra...@gmail.com>.
Thilina,
Here is my concern. If you have application scope the expectation is that we
have a single instance throught the life of the app.
So I could be initializing very expensive stuff in my init() and thats ok
bcos the expectation is that you do that only once.
Imagine if we have to do this for every invocation bocs we choose to create
a new object for every invocation?
This could be a severe performance hit as I maybe doing very expensive
object creations.
So in my opinion we have to look at a different stratergy from a performance
POV.
Regards,
Rajith
On 10/10/06, Thilina Gunarathne <cs...@gmail.com> wrote:
>
> Ok... Here's my suggestion.. Let's create new service objects per
> invocation..
>
> AFAIK two things happen when we deploy a service in application scope.
> One is that Axis2 will maintain a single service context throughout
> the life of the service.. Other thing is Axis2 maintains one service
> class object throughout the life of the service, serving for all the
> requests..
>
> Maintaining of the service context is really important and useful..
> Users can use it to store whatever the state data that needs to shared
> throughout the life of the service. IIRC this is one of the use cases
> we came up with for the Axis2 context hierarchy- to make the engine
> stateless..
>
> On the other hand, i don't see any reason for maintaining a single
> service object throughout the life of the service. IMO anybody can use
> the ServiceContext to store whatever the state data needed to be
> shared across the life of the service...Are there any special cases
> where we can't do that.. If there aren't any reasons my suggestion is
> to create the service object per invocation.
>
> Also a user who uses the application scope might most probably be
> working in the messagereceiver(MR) level, since MR is known to be the
> ultimate message recipient in Axis2. One possible example is a BPEL
> engine.. In that case the concept of one service object for the life
> time of the service invalidates.. AFAIKS AXIS2-1133 is another
> implication of this design...
>
> Thanks,
> Thilina
>
> On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > 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.xmlparam 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
> >
> >
>
>
> --
> http://webservices.apache.org/~thilina/
> http://thilinag.blogspot.com/
>
> ---------------------------------------------------------------------
> 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 Thilina Gunarathne <cs...@gmail.com>.
Ok... Here's my suggestion.. Let's create new service objects per invocation..
AFAIK two things happen when we deploy a service in application scope.
One is that Axis2 will maintain a single service context throughout
the life of the service.. Other thing is Axis2 maintains one service
class object throughout the life of the service, serving for all the
requests..
Maintaining of the service context is really important and useful..
Users can use it to store whatever the state data that needs to shared
throughout the life of the service. IIRC this is one of the use cases
we came up with for the Axis2 context hierarchy- to make the engine
stateless..
On the other hand, i don't see any reason for maintaining a single
service object throughout the life of the service. IMO anybody can use
the ServiceContext to store whatever the state data needed to be
shared across the life of the service...Are there any special cases
where we can't do that.. If there aren't any reasons my suggestion is
to create the service object per invocation.
Also a user who uses the application scope might most probably be
working in the messagereceiver(MR) level, since MR is known to be the
ultimate message recipient in Axis2. One possible example is a BPEL
engine.. In that case the concept of one service object for the life
time of the service invalidates.. AFAIKS AXIS2-1133 is another
implication of this design...
Thanks,
Thilina
On 10/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> 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
>
>
--
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/
---------------------------------------------------------------------
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 Tom Jordahl <tj...@adobe.com>.
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 Sanjiva Weerawarana <sa...@opensource.lk>.
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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Posted by Davanum Srinivas <da...@gmail.com>.
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
>
>
--
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] Improvements to Service life cycle in handling -
setOperationContext not thread-safe??!!
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext
not thread-safe??!!
Posted by Christopher Sahnwaldt <ch...@gmx.net>.
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
Re: [axis2] Improvements to Service life cycle in handling - setOperationContext not thread-safe??!!
Posted by Davanum Srinivas <da...@gmail.com>.
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
>
>
--
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] Improvements to Service life cycle in handling - setOperationContext
not thread-safe??!!
Posted by Christopher Sahnwaldt <ch...@gmx.net>.
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
Re: [axis2] Improvements to Service life cycle in handling
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-09-18 at 13:45 +0530, Deepal Jayasinghe wrote:
> >How about this- rather than putting these methods into an interface and
> >asking people to implement them, let's have these methods documented and
> >then reflectively call them if they're there. The advantage of this
> >approach is that it can work even for non-Java services. Suppose a
> >service is implemented in JavaScript or Groovy- we can let that message
> >receiver do whatever it needs to do the right thing. Having a Java
> >interface name is Java-specific.
> >
> >
> The interface I am talking here is somewhat similar to Module interface
> , so which is optional interface.
The difference Deepal is that the user *may* offer a class which
implements the module interface or not. If they don't we don't go
looking in some other class whether they just happened to have methods
we were looking for via the Module interface. That's sort of what you're
doing now in the lifecycle stuff.
> And there is no any relationship with
> service impl class (class specified by <parameter name="ServiceClass">).
> No matter whether the service impl class is Java or Non-Java , if user
> has implement the class and specified then we will call that.
I understand that but we must not preclude a Javascript user from
writing the service lifecycle logic in Javascript right? In that case,
the message receiver can still do the same thing.
Yes I know having an interface does not preclude the Javascript message
receiver from doing whatever it wants. So I'll live with having the
interfaces, but not with ignoring it if we have it.
(The reason I'd rather *not* have the interfaces at all is because we're
reinventing the pain of EJBs etc. by doing this. A lesson to be learnt
from that experience IMO is that lots of programming model rules is hard
to deal with. The lesson to be learnt from Ruby on Rails and Spring is
that conventions are easier for people to deal with. Thus: No
interfaces; just methods.)
> Service impl class SHOULD NOT implement that , and even if he does we do
> not care (we will call them) , he has to give separate impl class of
> that particular interface in services.xml.
Sorry but I can't parse that sentence. Can you explain please?
> In java case there will be two class , ;
> - service impl class
> - class which implements the interface
Fine with me. (We could have 3 classes of course- one for the
ServiceLifecycle and another for the ServiceSessionLifecycle in addition
to the service class itself. BTW shall we
s/ServiceSessionLifecyle/ServiceContextLifecycle/ ?? That's what it is
exactly; session is *a* way of using a service context.)
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
Posted by Deepal Jayasinghe <de...@opensource.lk>.
>(Deepal you forgot the [axis2] on the subject! For others who missed the
>rest of the thread; please go look in your axis-dev folder.)
>
>
oh , I am sorry for not putting [Axis2]
>I'm +1 for doing this. ServiceLifecycle is still not the right name IMO
>for the features it has- it should be ServiceSessionLifecycle:
>
+1 for ServiceSessionLifecycle
> what its
>doing is allowing you to be notified when the session is inited and
>destroyed and also when an operation context is created within that
>session (which happens multiple times within a service session). So its
>even more than ServiceSessionLifecycle- its that plus operation context
>notification.
>
>
Agreed, as I can see if some one try to access any context inside the
service impl class , then he is doing smt related to the session.
Therefore I think each of those operations belongs to the life cycle of
the session.
>I'm very uncomfortable with calling the other interface Service. What
>its really doing is notifying the service impl logic when the service is
>inited/destroyed. So its really ServiceLifecycle.
>
yes , it is service life cycle , which happen irrespective of the
service scope.
>
>
>How about this- rather than putting these methods into an interface and
>asking people to implement them, let's have these methods documented and
>then reflectively call them if they're there. The advantage of this
>approach is that it can work even for non-Java services. Suppose a
>service is implemented in JavaScript or Groovy- we can let that message
>receiver do whatever it needs to do the right thing. Having a Java
>interface name is Java-specific.
>
>
The interface I am talking here is somewhat similar to Module interface
, so which is optional interface. And there is no any relationship with
service impl class (class specified by <parameter name="ServiceClass">).
No matter whether the service impl class is Java or Non-Java , if user
has implement the class and specified then we will call that.
Service impl class SHOULD NOT implement that , and even if he does we do
not care (we will call them) , he has to give separate impl class of
that particular interface in services.xml.
In java case there will be two class , ;
- service impl class
- class which implements the interface
>Performance-wise, the startup(AxisService,ConfigurationContext (I
>presume)) and shutdown() are only called on loading/shutdown, the
>init(ServiceContext)/destroy(ServiceContext) is only called once per
>session. and setOperationContext is the only one that's costly because
>we'd have to reflect to check whether the method is there and only call
>if its there. (Catching the exception is more costly!)
>
>
I personaly like to have both the ways;
- allow user to implement that interface , if he does we first check
the instance and invoke , else
- using reflection , check to see whether method is there if yes ,
then call the method using java reflection.
>So, my proposal would be to document these methods and invoke them at
>the right time if they're there. No interfaces.
>
>
I am +1 on document them properly , and to have the interfaces
optionally (as we have now).
Deepal
---------------------------------------------------------------------
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
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
No I don't think that's a good approach: That basically says we couldn't
agree so we did both. Defining the interface and not using it doesn't
make sense; what I'm suggesting is to inject the extra info to the app,
which is of course very popular as the way to get data into an app.
Sanjiva.
On Sat, 2006-09-16 at 14:57 -0400, Davanum Srinivas wrote:
> Sanjiva,
>
> How about this? We define the interface, If people want to use it,
> they can. But our code will be smart enough to reflectively look for
> the method+parameters and call it even if the class does not implement
> the interface. An interface is good for documenting the capabilities
> in a easy to understand form for our users.
>
> -- dims
>
> On 9/16/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> > (Deepal you forgot the [axis2] on the subject! For others who missed the
> > rest of the thread; please go look in your axis-dev folder.)
> >
> > I'm +1 for doing this. ServiceLifecycle is still not the right name IMO
> > for the features it has- it should be ServiceSessionLifecycle: what its
> > doing is allowing you to be notified when the session is inited and
> > destroyed and also when an operation context is created within that
> > session (which happens multiple times within a service session). So its
> > even more than ServiceSessionLifecycle- its that plus operation context
> > notification.
> >
> > I'm very uncomfortable with calling the other interface Service. What
> > its really doing is notifying the service impl logic when the service is
> > inited/destroyed. So its really ServiceLifecycle.
> >
> > How about this- rather than putting these methods into an interface and
> > asking people to implement them, let's have these methods documented and
> > then reflectively call them if they're there. The advantage of this
> > approach is that it can work even for non-Java services. Suppose a
> > service is implemented in JavaScript or Groovy- we can let that message
> > receiver do whatever it needs to do the right thing. Having a Java
> > interface name is Java-specific.
> >
> > Performance-wise, the startup(AxisService,ConfigurationContext (I
> > presume)) and shutdown() are only called on loading/shutdown, the
> > init(ServiceContext)/destroy(ServiceContext) is only called once per
> > session. and setOperationContext is the only one that's costly because
> > we'd have to reflect to check whether the method is there and only call
> > if its there. (Catching the exception is more costly!)
> >
> > So, my proposal would be to document these methods and invoke them at
> > the right time if they're there. No interfaces.
> >
> > Sanjiva.
> >
> > On Fri, 2006-09-15 at 09:29 -0400, 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
Re: [axis2] Improvements to Service life cycle in handling
Posted by Davanum Srinivas <da...@gmail.com>.
Absolutely Deepal. I was suggesting that we should use the same
pattern we have already set.
thanks,
dims
On 9/18/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi dims;
> This is what we have right now , I mean one can implement Service
> interface or just have session related method in the service impl class.
> - if he has implement the interface , then we check the instance of the
> service impl class , then call method accordingly
> - else we check to see whether those method are there in the service
> impl class , and if there are there we call them using java reflection.
>
> So I am +1 to have that.
>
> > Sanjiva,
> >
> > How about this? We define the interface, If people want to use it,
> > they can. But our code will be smart enough to reflectively look for
> > the method+parameters and call it even if the class does not implement
> > the interface. An interface is good for documenting the capabilities
> > in a easy to understand form for our users.
> >
>
>
> ---------------------------------------------------------------------
> 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] Improvements to Service life cycle in handling
Posted by Christopher Sahnwaldt <ch...@gmx.net>.
> Are there any other well-known systems which have this dual mode behavior?
Here's how Spring does it: users can either implement certain interfaces
(InitializingBean, DisposapleBean), and Spring will automatically call
the init and destroy method. Or they can add attributes to their bean
definition: <bean class="MyClass" init-methd="myInit" destroy-method="myDestroy">.
I think that's a pretty good compromise:
- if you're ok with tying your classes to the framework - use the interfaces.
- if you can't or don't want to do that, reflection will only be used to
look for methods that you said exist, so there's no useless searching.
http://www.springframework.org/docs/reference/beans.html#beans-factory-lifecycle
Christopher.
Sanjiva Weerawarana wrote:
> On Mon, 2006-09-18 at 13:49 +0530, Deepal Jayasinghe wrote:
>
>> Hi dims;
>> This is what we have right now , I mean one can implement Service
>> interface or just have session related method in the service impl class.
>> - if he has implement the interface , then we check the instance of the
>> service impl class , then call method accordingly
>> - else we check to see whether those method are there in the service
>> impl class , and if there are there we call them using java reflection.
>>
>> So I am +1 to have that.
>>
>
> I didn't realize that this is the behavior we have now. What's the
> purpose of having the interface if we don't require people to implement
> it? IMO that makes no sense.
>
> Either do the interface or don't. Doing both is hacky.
>
> [Are there any other well-known systems which have this dual mode
> behavior? Maybe that'll help convince me. Otherwise I'm against keeping
> both. (I'll refrain from using negative numbers for now ;-)).]
>
> 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] Improvements to Service life cycle in handling
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Sanjiva Weerawarana wrote:
>On Tue, 2006-09-19 at 09:43 +0530, Deepal Jayasinghe wrote:
>
>
>>Well , then let's go with the following approach;
>> - To manage service session life cycle , there is no interface. If user
>>want to need to get access to any context then he need to add those
>>three method in to service impl class (init , setOperationConetxt , destroy)
>>
>>
>
>BTW even if we were going with interfaces we'd have to separate
>setOperationContext because that's totally different from the service
>context lifecyle.
>
>
>
>>- To mange service life cycle (which call at the deployment time , and
>>when the system goes down), he MUST implement an interface and specified
>>that in services.xml as follows
>><service name="foo" class="interface impl class">
>>
>>
>
>+1 from me.
>
>Can we agree to document them as:
>
>- if you want to monitor service context lifecycle then implement
>init(ServiceContext)/destroy(ServiceContext)
>- if you want to monitor operation context lifecycle then implement
>setOperationContext(OperationContext)
>- if you want to do something when the service is loaded and off loaded,
>then implement the ServiceLifecycle interface and give that class to us
>
>I'm not thrilled with the method names we have but I'm fine with the
>design. Anyone ideas for better names (from anyone)?
>
>
I am fine with the name ( :) ) , so I will do the changes.
Thanks
Deepal
---------------------------------------------------------------------
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
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2006-09-19 at 13:50 -0400, Tony Dean wrote:
> I agree with your descriptions below... but, can you clarify in the
> case of ServiceLifecycle (startup, shutdown) why you need to specify
> the class that implements them. Why can't all the lifecycles
> (ServiceContextLifecyle (or SessionContextLifecycle),
> OperationContextLifecycle, and ServiceLifecycle be implemented in the
> service impl class: <service name=""> <parameter
> name="ServiceClass">com.xxx.myImplClass</parameter> </service>
>
> com.xxx.myImplClass can choose to implement all or none of the lifecycle methods.
The problem is that the service lifecycle methods are invoked upon
service load and unload. At that time there's no instance of the service
class around (unless the scope of the service was application in which
case it could). As such having these methods in the service class
creates an awkward lifecycle for the service class itself. (I'm
presuming that you don't want it new'd and free'd just to invoke the
service lifecycle methods.)
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
Posted by Tony Dean <To...@sas.com>.
I agree with your descriptions below... but, can you clarify in the case of ServiceLifecycle (startup, shutdown) why you need to specify the class that implements them. Why can't all the lifecycles (ServiceContextLifecyle (or SessionContextLifecycle), OperationContextLifecycle, and ServiceLifecycle be implemented in the service impl class:
<service name="">
<parameter name="ServiceClass">com.xxx.myImplClass</parameter>
</service>
com.xxx.myImplClass can choose to implement all or none of the lifecycle methods.
thanks.
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Tuesday, September 19, 2006 12:05 PM
To: axis-dev@ws.apache.org
Subject: Re: [axis2] Improvements to Service life cycle in handling
On Tue, 2006-09-19 at 09:43 +0530, Deepal Jayasinghe wrote:
> Well , then let's go with the following approach;
> - To manage service session life cycle , there is no interface. If
> user want to need to get access to any context then he need to add
> those three method in to service impl class (init ,
> setOperationConetxt , destroy)
BTW even if we were going with interfaces we'd have to separate setOperationContext because that's totally different from the service context lifecyle.
> - To mange service life cycle (which call at the deployment time , and
> when the system goes down), he MUST implement an interface and
> specified that in services.xml as follows <service name="foo"
> class="interface impl class">
+1 from me.
Can we agree to document them as:
- if you want to monitor service context lifecycle then implement
init(ServiceContext)/destroy(ServiceContext)
- if you want to monitor operation context lifecycle then implement
setOperationContext(OperationContext)
- if you want to do something when the service is loaded and off loaded, then implement the ServiceLifecycle interface and give that class to us
I'm not thrilled with the method names we have but I'm fine with the design. Anyone ideas for better names (from anyone)?
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] Improvements to Service life cycle in handling
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2006-09-19 at 09:43 +0530, Deepal Jayasinghe wrote:
> Well , then let's go with the following approach;
> - To manage service session life cycle , there is no interface. If user
> want to need to get access to any context then he need to add those
> three method in to service impl class (init , setOperationConetxt , destroy)
BTW even if we were going with interfaces we'd have to separate
setOperationContext because that's totally different from the service
context lifecyle.
> - To mange service life cycle (which call at the deployment time , and
> when the system goes down), he MUST implement an interface and specified
> that in services.xml as follows
> <service name="foo" class="interface impl class">
+1 from me.
Can we agree to document them as:
- if you want to monitor service context lifecycle then implement
init(ServiceContext)/destroy(ServiceContext)
- if you want to monitor operation context lifecycle then implement
setOperationContext(OperationContext)
- if you want to do something when the service is loaded and off loaded,
then implement the ServiceLifecycle interface and give that class to us
I'm not thrilled with the method names we have but I'm fine with the
design. Anyone ideas for better names (from anyone)?
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
Posted by Deepal Jayasinghe <de...@opensource.lk>.
>I didn't realize that this is the behavior we have now. What's the
>purpose of having the interface if we don't require people to implement
>it? IMO that makes no sense.
>
>Either do the interface or don't. Doing both is hacky.
>
>[Are there any other well-known systems which have this dual mode
>behavior? Maybe that'll help convince me. Otherwise I'm against keeping
>both. (I'll refrain from using negative numbers for now ;-)).]
>
>
>
Well , then let's go with the following approach;
- To manage service session life cycle , there is no interface. If user
want to need to get access to any context then he need to add those
three method in to service impl class (init , setOperationConetxt , destroy)
- To mange service life cycle (which call at the deployment time , and
when the system goes down), he MUST implement an interface and specified
that in services.xml as follows
<service name="foo" class="interface impl class">
---------------------------------------------------------------------
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
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-09-18 at 13:49 +0530, Deepal Jayasinghe wrote:
> Hi dims;
> This is what we have right now , I mean one can implement Service
> interface or just have session related method in the service impl class.
> - if he has implement the interface , then we check the instance of the
> service impl class , then call method accordingly
> - else we check to see whether those method are there in the service
> impl class , and if there are there we call them using java reflection.
>
> So I am +1 to have that.
I didn't realize that this is the behavior we have now. What's the
purpose of having the interface if we don't require people to implement
it? IMO that makes no sense.
Either do the interface or don't. Doing both is hacky.
[Are there any other well-known systems which have this dual mode
behavior? Maybe that'll help convince me. Otherwise I'm against keeping
both. (I'll refrain from using negative numbers for now ;-)).]
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
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi dims;
This is what we have right now , I mean one can implement Service
interface or just have session related method in the service impl class.
- if he has implement the interface , then we check the instance of the
service impl class , then call method accordingly
- else we check to see whether those method are there in the service
impl class , and if there are there we call them using java reflection.
So I am +1 to have that.
> Sanjiva,
>
> How about this? We define the interface, If people want to use it,
> they can. But our code will be smart enough to reflectively look for
> the method+parameters and call it even if the class does not implement
> the interface. An interface is good for documenting the capabilities
> in a easy to understand form for our users.
>
---------------------------------------------------------------------
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
Posted by Davanum Srinivas <da...@gmail.com>.
Sanjiva,
How about this? We define the interface, If people want to use it,
they can. But our code will be smart enough to reflectively look for
the method+parameters and call it even if the class does not implement
the interface. An interface is good for documenting the capabilities
in a easy to understand form for our users.
-- dims
On 9/16/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> (Deepal you forgot the [axis2] on the subject! For others who missed the
> rest of the thread; please go look in your axis-dev folder.)
>
> I'm +1 for doing this. ServiceLifecycle is still not the right name IMO
> for the features it has- it should be ServiceSessionLifecycle: what its
> doing is allowing you to be notified when the session is inited and
> destroyed and also when an operation context is created within that
> session (which happens multiple times within a service session). So its
> even more than ServiceSessionLifecycle- its that plus operation context
> notification.
>
> I'm very uncomfortable with calling the other interface Service. What
> its really doing is notifying the service impl logic when the service is
> inited/destroyed. So its really ServiceLifecycle.
>
> How about this- rather than putting these methods into an interface and
> asking people to implement them, let's have these methods documented and
> then reflectively call them if they're there. The advantage of this
> approach is that it can work even for non-Java services. Suppose a
> service is implemented in JavaScript or Groovy- we can let that message
> receiver do whatever it needs to do the right thing. Having a Java
> interface name is Java-specific.
>
> Performance-wise, the startup(AxisService,ConfigurationContext (I
> presume)) and shutdown() are only called on loading/shutdown, the
> init(ServiceContext)/destroy(ServiceContext) is only called once per
> session. and setOperationContext is the only one that's costly because
> we'd have to reflect to check whether the method is there and only call
> if its there. (Catching the exception is more costly!)
>
> So, my proposal would be to document these methods and invoke them at
> the right time if they're there. No interfaces.
>
> Sanjiva.
>
> On Fri, 2006-09-15 at 09:29 -0400, 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
>
>
--
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] Improvements to Service life cycle in handling
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
(Deepal you forgot the [axis2] on the subject! For others who missed the
rest of the thread; please go look in your axis-dev folder.)
I'm +1 for doing this. ServiceLifecycle is still not the right name IMO
for the features it has- it should be ServiceSessionLifecycle: what its
doing is allowing you to be notified when the session is inited and
destroyed and also when an operation context is created within that
session (which happens multiple times within a service session). So its
even more than ServiceSessionLifecycle- its that plus operation context
notification.
I'm very uncomfortable with calling the other interface Service. What
its really doing is notifying the service impl logic when the service is
inited/destroyed. So its really ServiceLifecycle.
How about this- rather than putting these methods into an interface and
asking people to implement them, let's have these methods documented and
then reflectively call them if they're there. The advantage of this
approach is that it can work even for non-Java services. Suppose a
service is implemented in JavaScript or Groovy- we can let that message
receiver do whatever it needs to do the right thing. Having a Java
interface name is Java-specific.
Performance-wise, the startup(AxisService,ConfigurationContext (I
presume)) and shutdown() are only called on loading/shutdown, the
init(ServiceContext)/destroy(ServiceContext) is only called once per
session. and setOperationContext is the only one that's costly because
we'd have to reflect to check whether the method is there and only call
if its there. (Catching the exception is more costly!)
So, my proposal would be to document these methods and invoke them at
the right time if they're there. No interfaces.
Sanjiva.
On Fri, 2006-09-15 at 09:29 -0400, 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
RE: Improvements to Service life cycle in handling
Posted by Tony Dean <To...@sas.com>.
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