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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
>> > > > >> > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> > > > >> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > >> >>
>> > > > >> >>
>> > > > >> >>
>> > > > >> >
>> > > > >> >
>> ---------------------------------------------------------------------
>> > > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> ---------------------------------------------------------------------
>> > > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >>
>> ---------------------------------------------------------------------
>> > > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > >> For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > >>
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > >
>> > >
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
