Alexey, as I mentioned, at now we have same implementation for IgniteMXBean and Ignite in IgniteKernal. Already is. I agree, the implementations should be decoupled. But extracting IgniteMXBean from IgniteKernal seems too bulky solution to me. Tacking in account lot of variants of deactivation methods (many deprecated) and invocation points I propose to bring single centralized solution.
пн, 17 февр. 2020 г. в 16:59, Alexey Goncharuk <alexey.goncha...@gmail.com>: > пн, 17 февр. 2020 г. в 14:18, Vladimir Steshin <vlads...@gmail.com>: > > > > The only reason is the same implementation IgniteMXBean#active(boolean) > > > and Ignite#active(boolean). Looks like we have to choose whether to > allow > > > user erase data unexpectedly or to change behavior of the API call. > > > > Vladimir, those two interfaces (IgniteMXBean and Ignite) are decoupled and > must not share the same implementation. Internally, we can route the > methods to separate implementations. Or am I missing something? > > For me the analogy is pretty simple - we do have to specify an additional > flag for 'rm' command, but we do not have any confirmation flags for > syscalls. > > --AG >
