Jeremy Boynes wrote:
Tom McQueeney wrote:
Matt Hogstrom wrote:
I like the idea. I'd add that it would be nice to use a scheme such
as linux does for startup / shutdown with a letter designator and a
number in the rc.n directories. That scheme allows a lot of
flexibility and control as well. I also like the runLast / runFirst
idea but there can only be one first and last :)
Thanks for your feedback. How about a boolean runAtEnd to kinda imply
it won't be the last, but it will be run toward the end? This would be
easy to implement.
Maybe Dain can answer this, but perhaps a completely different
solution is not to use a shutdown hook at all in the
FileConfigurationList GBean. Maybe the GBean should save the name of
running configurations at doStop time. At first glance, I can't see a
reason why this solution wouldn't work, since I don't think other
GBeans write to the config.list store, but maybe other components read
the file and would break if the file were changed while the server was
running and someone stopped the FileConfigurationList GBean.
The above change would solve the problem with the FileConfigList GBean
but maybe cause problems in the future for other shutdown hooks.
(Currently, only two GBeans register shutdown hooks with the kernel.)
The primary problem with the configuration manager's shutdown hook
running first is it stops all the GBeans. Any kernel references the
other GBean shutdown hooks have become stale proxies afterword, making
any work they need to do with the other components a little difficult.
Probably better is to not do this automatically on shutdown at all as at
that time you are not certain that the configurations are actually good.
Instead, how about sending a notification out when the set of
Configurations that are /meant/ to be running changes (e.g. at the end
of a JSR88 start operation) and have the FCL GBean listen for those
notifications and update its state then.
Jeremy: Thank you for the advice. I can see updating the config.list
when a configuration is started or stopped is a better solution. It
would allow cleaner server restart after an unexpected shutdown.
Unfortunately, this better solution involves areas of Geronimo I'm
unfamiliar with. I'm still interested in fixing this bug more elegantly,
so any advice you can give on where the jsr-88 start (and stop?)
operations take place would be appreciated. Also, regarding the FCL
listening for stop/start events, would this be via a LifecycleListener?
The FCL would register for events coming from the
PersistentConfigurationList objectname?
-Tom
--
Jeremy
- Re: [jira] Commented: (GERONIMO-657) Running configurations ... Tom McQueeney
-
