On Aug 30, 2012, at 4:49 PM, Anthony Fryer wrote: > Are you guys thinking of providing an mbean interface to the java config api? > I used to work a fair bit on weblogic and they had configuration mbeans that > you could use to change the configuration. I think this is how they manage > clustered environments where the admin server talks to the managed servers > via the mbean interface. The configuration mbeans would update the xml > configuration file as well to persist the configuration changes. There was > a clear delineation between configuration and runtime mbeans. Sounds like > the java config api could form the basis of configuration mbeans if you > wanted to go down that path.
We have some MBeans in place already for runtime configuration and definitely we plan to have more. Currently what is there for runtime is full configuration of the Stateless container (it has a lot of pooling options) and the ability to redeploy persistence units (free up memory) and datasources (resets pools). More comprehensive configuration MBeans would definitely be great. In terms of clustered environments, we have a rather interesting setup I'm really looking forward to putting to the test. We put a lot of work into canonicalizing configuration down to this one universal tree that is easily serializable. Think of it as an AST -- it's not pretty to look at like source code, but the actual configuration with the fanciness stripped away. In this setup you can theoretically boot several servers with essentially no configuration files, just give each node the fully canonicalized configuration and they can just construct the related runtime objects. Some info here: - http://tomee.apache.org/dev/configuration-and-assembly.html Effectively all the config stuff is really synonymous to adding another "source code" format that we will eventually "compile" down to the same medium. It does make it quite tricky to reverse that process. If someone make a change to something at runtime, to then go the other direction and push that out to config files becomes tricky -- what particular source file format did they use? On the positive side it also allows us to support descriptors of other vendors quite easily. We just translate them into our own on the fly. So far that just works for GlassFish descriptors and to a lesser extent Geronimo descriptors. -David
