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 <[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] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
