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