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.
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.
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.
Ok, looking inside the Startup interface it only sounds to be generic but
infact it seems to be just a synonym for task, or?
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.
What are other’s opinions? How shall we go on? Ruwan, would you do those
changes on your own. 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.
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.
Regards,
Eric
