How can you make an application master of management objects like jdbc-connections?
How to use the management api at startup of an application while still using synchronous ModelControllerClient.execute calls?
I'm having two major issues when using the management api at startup of my application.
Please consider my current situation.
I'm creating an application that contains it's own configuration of jdbc-connections, messaging objects, schedulers etc (lets call this application the Repo).
To work with these objects the Repo needs to configure these objects at its own startup in the JBoss runtime. To do this we decided to use the management api (DMR), because it looks very promissing.
I'm currently facing two major issues with this aproach.
1. The changes made to the JBoss runtime are all persisted in the config file of JBoss. I've asked in another post and there is no way to disable this. This raises issues on how to synchronise the Repo config and the JBoss config. One workaround would be to first delete all JBoss management objects at start up of the Repo and then create them again (huge overhead), a second workaroung would exist of keeping a list of all created/updated management objects and remove the ones that still exist in JBoss but no longer in the Repo config (less overhead, but complex). Maybe I'm doing things totally wrong? Are there better approaches? Anyway, when implementing these workarounds I came a accross a second even bigger problem.
2. To deploy an application (like our Repo) JBoss uses the management api itself, which results in a dead-lock. Apparantly it is not possible to run ModelControllerClient.execute synchronously while being in another instance of this execute method. So for example when I want to run the add operation to create a jdbc-connection in the startup of the Repo the application hangs because the deployment of the Repo is running inside an execute of the deploy operation by JBoss. A workaround for this issue would exist in calling the ModelControllerClient.executeAsync method. This works fine but complicates the workarounds for my first issue gravely. For example the remove all approach (see issue 1) requires me to first get a list of all connections, but this would require me to write custom callback handlers for the async call. This all seems very complicated and fare sought I believe.
I have the feeling that my approach is not the right one here? Do you have any suggestion on this? The fact the Repo is the master of the management objects is however really required for our setup.
Thanks for your help