Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: JSON for mod_status
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <CACsi2508fSZ+C_TFtF0jY6R+9XM2iT06P--oPGNJaeWnTP6KGA@mail.gmail.com>
Date: Thu, 1 Dec 2016 13:33:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <30A04E20-B8B3-428C-98AC-011203591A89@jaguNET.com>
References: <128EB450-7EF2-44CD-9D0A-9B1AA913AC2F@jaguNET.com> <1480531092.4019.27.camel@mimir.webthing.com> <CACsi250F72DHGcuZNnanB1m5ZNgBAr4sWBM=X=fQnjPM+vzv8w@mail.gmail.com> <FD7C1D67-C868-42F7-A79F-2F38CEB309C0@jaguNET.com> <CACsi251Tqh63jbYDANDttr-m9YRCwO87RwG6_ZhQnjqKP_Bsbg@mail.gmail.com> <D04730C4-C7B4-4C9E-A4EA-F1FF73939663@jaguNET.com> <CACsi253qtj-6-E8eMskWg_usAUGTrMLi0u89f5qZpHWCJ66Xnw@mail.gmail.com> <73D2DF78-864E-40E2-B20E-8348060763BF@jaguNET.com> <CACsi253K1MCfP_p1xF8erW+jm7dTv=Gmvnyvrjdk0YCcNKxO+A@mail.gmail.com> <B3606618-7563-412D-BAB5-12CE6330AB12@jaguNET.com> <CACsi2505fZLCcKd2MnLFtbdcq6YHxUEu2U7AxScsPQe+wEDioQ@mail.gmail.com> <D1BD6738-6A8D-433C-A22F-354116C2955A@jaguNET.com> <CACsi250qwpWHPaiGz3_Kkfv0M0x09kJuR8mzq-DJxoP71tzyLg@mail.gmail.com> <CACsi25126Ecna12GnfkL4bgn8fYMhdJ9yoZc03ooau6JBoVwww@mail.gmail.com> <CACsi253NAO+dUa6owvH5JCvngUMUpWgg58g1yGP_UTTtwkmtBg@mail.gmail.com> <C1BE2FED-C128-4DEB-B8AA-2D3D57DEB8B1@jaguNET.com> <CACsi2508fSZ+C_TFtF0jY6R+9XM2i
 T06P--oPGNJaeWnTP6KGA@mail.gmail.com>
To: dev@httpd.apache.org
archived-at: Thu, 01 Dec 2016 18:35:18 -0000


> On Dec 1, 2016, at 12:53 PM, William A Rowe Jr <wrowe@rowe-clan.net> =
wrote:
>=20
>=20
> 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);
>=20
>     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);
>=20
>=20

OK, this is the point I have the question about. =46rom what
I can see, mod_bmx_status creates bmx_status_bean, adds stuff
to it, and then prints it out.

But how does it get access to, for example, the beans created and
populated in mod_bmx_vhost? I understand that if you KNOW what
beans you are looking for, you can query them via mod_bmx, but
how do you know what beans have been added.

Right now, for example, we have a simple hook that mod_socache_redis
(for example) hooks into and once mod_status is done, it loops
through all registered hooks. But I don't see any similar type of
functionality in mod_bmx_status which allows mod_bmx_status to
reproduce the full status information that mod_status currently
does.

So yeah, other modules create their beans. Fine. But how
do those beans get "registered" in mod_bmx_status so that they
can actually be displayed?=