On Thu, Dec 1, 2016 at 8:08 AM, Jim Jagielski <j...@jagunet.com> wrote:
> My question is how do the beans, for example, from mod_bmx_vhost > get displayed via mod_bmx_status? > > I understand that one queries mod_bmx for specific beans, but at > the end of the day people still want/need a comprehensize > mod_status-like display. My expectation would be that mod_bmx_status > would provide that. > mod_bmx is the hub module which handles the bmx-handler generator. Configuration is as straightforward as compiling in or loading mod_bmx.so and following a typical server-status handler config; <Location /bmx> SetHandler bmx-handler Require ip 127.0.0.1 </Location> What mod_bmx reports depends on who hooks into it. You can run it by only loading mod_bmx_status, or only mod_bmx_vhost, or any combination of multiple providers. An obvious new extension would be mod_proxy_balancer pool load reporting. mod_bmx_status hooks into this framework by setting a server-lifetime bean indicating that ServerStatus is extended or not, and then hooks into the mod_bmx query hook during the pre-config phase; APR_OPTIONAL_HOOK(bmx, query_hook, bmx_status_query_hook, NULL, NULL, APR_HOOK_MIDDLE); Our mod_bmx_status query_hook handler is a fairly typical 'handler', of data instead of content; static int bmx_status_query_hook(request_rec *r, const struct bmx_objectname *query, bmx_bean_print print_bean_fn) We don't want to refresh our data if the query indicates that the request to the bmx-handler excluded server-status data, so there's a short circuit right off the bat. Provided some subset of server-status data is needed, this function continues by populating the data for mod_bmx to present (which it can further filter by item name without help from the extensions). Finally the query fn in mod_bmx_status performs the callback indicated through its invocation to unspool the data in presentation format, which lives back in mod_bmx and behaves identically for every bmx extension. Adding the properties by type takes all of the onus off of each extension to know how to represent them once stored. E.g. our query_hook function can be as simple as; /* create the bean */ bmx_bean_create(&bmx_status_bean, bmx_status_objectname, r->pool); bmx_bean_prop_add(bmx_status_bean, bmx_property_string_create("ServerName", ap_get_server_name(r), r->pool)); print_bean_fn(r, bmx_status_bean); For Stefan's and others concerns, it would probably be most useful for Doug or Aaron to explain how they came to the bean datum model for representing bmx's results. .