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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Friday, September 15, 2006 8:49 AM > To: [email protected] > 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]
-- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
