Hi Eric, On Sat, Apr 4, 2009 at 1:51 PM, Hubert, Eric <[email protected]>wrote:
> I put my comments inline as well. > > > > Please see my comments inline; > > What I meant in my original proposal is exactly this, but without > preStart I think preStart is equivalent to the init, but we need postStart > or some other meaning full method to do post startup tasks. > > Yeah, at the moment I sent my mail out I also came across the same thought. > Did you notice my follow-up mail on this? I think we could put all calls in > a start() method which delegates to the specific sub routines in the > appropriate order. Actually also the tasks are part of the start process. > It’s only the fact they are started after the listeners as they require them > to be started in advance. > How can we manage the case where the task sends a request out just after its initialization and before starting the listeners without having a post listener start phase to start the tasks, for example MessageInjector actually does this. > > > This may not be just the tasks but also some mediators which requires to > fetch some data from outside going through the transport senders at the > startup?? > > Can you give me an example here? It can’t be something which is done on > mediate() as this can only happen once a message arrives, and thus > transports are started. So you are talking about something which currently > happens inside the init method, which requires the transports to be > available. Hmmm, interesting… I have no use case in mind. Maybe other can > help on this. Actually if this would be the case I would find it consistent > to not only implement ManagedLifecylce but rather Startup and split the > implementation in a init-Phase were one can only do initialisation stuff > which does not require transports. And a start-Phase where one can do any > kind of one-time operation on startup also requiring the transports. > > Of course this would break existing mediators currently doing such stuff. > This is why I’m asking about examples and use cases. > True, I agree with all your concerns, but my point is that if we take just the tasks out of the normal ManagedLifecycles and call them after starting listeners, we are going with an assumption that task initialization is the one only requires transport listeners.... This is a bit confusing because we are using the same interface to mean two types of implementations and we manage them depending on our hard coded assumptions. I don't have a concrete example of such a case, but I think a start method apart from the init method is required. I am not in favor of adding this to the startup interface, because it is not intended to mark a life cycle rather it is a concrete component of the synapse.... Startup interface can be treated as same as the Mediator interface and the Task is the interface that we provide for the external users to write one type of startups, which is a quartz scheduled piece of work executed as Tasks. This is analogous to the Command mediator, Command Mediator is an implementation of the Mediator interface, where it provides the Command interface for the external users to write there own commands. One option would be to come up with a new interface to cope this new start method requirement which is extended from the ManagedLifecycle interface, but it introduces a new interface yet again keeps the back words compatibility for the already existing mediators. We should properly document this so that if a particular mediator wants to get this starting behavior it can also use the new derived interface over the ManagedLifecycle. > > > So if we add a new method to the ManagedLifecycle called start you could, > support these post startup work in a general manner rather than treating > tasks starting as a special case. > True, implementation of mediators would need to be changed either the one > or the other way. I just don’t see so many use cases for the start()-method, > but I may be wrong. Also any mediator could decide to implement > ManagedLifecycle or some more specific interface extended by the startup > behaviour. Otherwise you would often leave this method without > implementation. > +1, it is not going to be a Startup derived interface rather a new interface derived from the ManagedLifecycle, because Startups are more specific to task like components, with some more methods in it. > Ok, looking inside the Startup interface it only sounds to be generic but > infact it seems to be just a synonym for task, or? > Not really a synonym, I think I explained the relation between Startup and Task in the above section. > So I could also life with a ManagedLifecycle interface extended by a new > start() method keeping this method always empty for my use cases. Of course > this has also an advantage for the user. Only one interface to care about. > Agree, we could provide a abstract class with the startup method implemented to get rid of the blank implementation in each and every mediator. I prefer to change the ManagedLifecycle interface itself, but OK with going for a new interface as well. > > > What are other’s opinions? How shall we go on? Ruwan, would you do those > changes on your own. > I would like to do this on my own, after gathering the feedback and I think even now we are clear about certain things... so I will get started. > If you would need some support, I could do this today. Today I have some > hours I could spend. Tomorrow and next week doesn’t look too good on my > side. > Eric, I think it is better to do this by one person, after the implementation is completed I will let you all know for a review and for any changes/improvements. I think that is the practical model for this sort of a change. :-) > Otherwise I will proceed with my work on the JMX stuff to remove some open > issues as of the comments in the JIRA (the integration shouldn’t be done > before the startup/shutdown has been changed though, I will then sync and > update my patch accordingly) and a small patch regarding log output in the > http transports. Looks like either way I will find enough useful stuff to > help with today. > +1 Thanks, Ruwan > > > Regards, > > Eric > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
