Open StavrevaS opened 7 years ago
I favor the the second option. We should avoid config files outside of containers.
In case of failed oscm installation, the tommee admin GUI will also be unavailable normally the operator should check the logs why an installation fails, the UI admin console is not really necessary And if OSCM is not working, the whole TomEE is useless because we're in a specialized, contained environment.
The implemented solution was well suffient up to now. Nevertheless, let's revisit this issue once more.
I'm just thinking .... Would be nice for the operator, to have the option for enabling the TomEE admin GUI on-demand for use in non-productive environments. For instance, we had the need for executing MBeans that we deployed in an OSCM test environment. Sure there exists a solution for connecting both realms in OSCM. Due to lack of time for making the combined realms working, we chose another way for executing the MBeans. However, the services offered in the TomEE GUI could be helpful for many development, debugging and maintenance purposes.
In the current implementation, oscm realm and file-based tomee realm are active. The tomee admin must authenticate in both of them.
The file-based tomee realm should be initialized with with platform operator credentials in order to login to the tomee admin UI.
The platform operator will change his initial password. So there are 2 possibilities:
The second option seems to be more convenient, since normally the operator should check the logs why an installation fails, the UI admin console is not really necessary,