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