Agreed. These two cases could be handled separately or we could consider generalizing the user interface for component lifecycle to address these and other potentially confusing scenarios that will arise all at one go. I think that right now the user interface is technically correct but is not intuitive.
I'm not as sure that either the UI or the command line are technically correct today regarding restart ... but it's probably a bike shed issue. I think a reasonable expectation of a user after a restart is that the system is in the same state WRT active components prior to the restart. If we choose to keep the current behavior then we need to do a better job warning the user of the consequences and help by listing the components that are stopped and not restarted.
For the command line client maybe that is OK, but for the graphical UI we could allow the user to make more informed decisions by providing a better visual representation of the component hierarchy. Attaching the lifecycle controls to the Dependency Viewer might be a good first step.
Perhaps ... but the dependency viewer sometimes make it difficult to locate the module that you want to operate on and the dependencies are actually inverted from what is needed for these operations (the current dependencies show what cars/jars this module is dependent upon rather than which modules are dependent upon it which would be the ones affected by the operation).
Also, the lifecycle controls for components that are in the console's dependency path could be disabled since they are required by the viewer itself (they can still be controlled from the CLI). Just throwing out some ideas.
Yes, that is certainly the quick and easy way out ... which is also why I did some digging to understand the components that actually create problems for the console and/or the server. The real answer here is I think I need to take this discussion to the dev list soon but I'd like to get some more details first.