> > Separated configuration is so complicate. > Configuration is just for SystemManager's configuration. >
I decided to think. Some of my thoughts are below if you care to read them. Phoenix could, in theory, configure everything using the <mbean> format and JMX (at least if it required all Blocks to be MBeans). It would probably even be a more flexible solution, although more verbose. But currently it has it's own configuration format, and the two are in direct competition. In my opinion, keeping them separate would allow greater flexibility in the future -- although I'm not really in a position at the moment to judge the direction of the project ;). I'd be content, in the short term at least, to see more descriptive versions of the same thing (i.e. instead of <manager-adaptor-port>number</...> to configure the http adaptor, <http-adaptor><port>number</port></...>) until JMX configuration is given full consideration. I'm not really very passionate about the issue, though -- just very bored tonight. David Weitzman Some thoughts, which may be self-contradictory and unrelated: Thought 1) Services like the HTTP and RMI are not directly dependant on SystemManager, nor vice versa. The need for them to be associated is that there is no other way to register MBeans at the moment. Thought 2) The things currently managed by SystemManager come with the Phoenix binaries, and aren't going to gain any new functionality between releases, so dynamic configuration isn't strictly-speaking necessary. A simple but expressive and complete custom configuration would be more concise and require less knowledge of the inner workings of the services being configured, but would require modification any time new ways to access JMX are added.. Thought 3) Since the <mbean> format already exists and can be implemented without relying on any particular JMX vendor, directly using DOM would make an implementation reusable outside of Avalon (which may not matter). Thought 4) Phoenix does not currently provide a configuration method that allows the user to execute/make available arbitrary JMX-compliant beans. That is precisely the problem that the <mbean> format is designed to solve. That format is actually directly competing with Phoenix's own methods of configuration, just without inherent support for features like the Avalon lifecycle (which could easily be made available). It is a separate and complete solution -- why make it dependant on Phoenix configuration files? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
