Information Screens

Main: Listing of Servers

This screen is the first screen that comes up when the location for which this class was assigned as a handler is invoked. It lists the server objects that this running Apache process knows of. Note that if the servers are defined in such a way as to mean on-demand creation, then a given child process may not have all the configured servers in memory. This is by design, it is not a bug. See "Usage Within <Perl> Sections" in Apache::RPC::Server for details on configuring the RPC servers such that they are pre-loaded into all child processes.

Server: Details of a Server

Each of the known servers in the main screen links to this screen, which provides details on the specific server. Information such as when the server was started (which usually matches the time that Apache was started), when the specific child was started (which may not be the same), number of requests servered, and so forth is provided. Additionally, each of the methods that the server provides is listed in alphanumeric order, with a link to the next screen.

Method: Details of a Specific Method

For each of the known methods published by a server, this screen summarizes all that is known about the method itself. The signatures, help text and hidden status (whether the method is visible to the introspection API that is shipped with RPC::XML::Server) are all shown. Some optional information is shown if available: if the method has a version number associated with it, that is displayed. If the method was loaded from an external XPL file, the file path and modification-time are also displayed.

The primary purpose of this status system is to allow for checking the availability and sanity of the RPC servers themselves. For example, if a server is configured to auto-load methods, and automatically check for updates, the status system could confirm that a method is available or is at the correct version.

(Note that auto-loading and auto-updating are done on demand, when a call is made to the method in question. Thus, the status might not reflect changes until at least one call has been made. Further, if there are very many child processes handling the RPC servers, several calls may be necessary to ensure that the child process answering the status request also has the most up-to-date impression of the server.)

Class Methods

new(CLASS, ARGS)

This creates a new object of this class and returns a reference to it. The first argument is the class being created into, the remaining arguments are treated as key/value pairs (note: not a hash reference). At present, the only additional argument recognized is:

handler(CLASS, REQUEST)

This is the primary entry-point for the package. This is the handler defined for assignment to "PerlHandler" in a location configuration block. It is invoked by mod_perl as a method handler, thus the first argument is either the name of the class (in the case of class-method, or static, invocation) or the object configured as the handler. The second argument is the Apache request object itself.

This method derives the query parameters for the request from the Apache object, and treats them according to the type of information screen requested:

init_handler(CLASS, REQUEST)

This is a very simple handler designed for the PerlChildInitHandler phase. At present, it only does one simple task (and thus makes no direct use of either parameter passed to it by mod_perl). However, it is included mainly as a placeholder for possible future expansion. The current behavior is to check for the existence of directory-configuration item called "ServerClass", and record the value if it is set. This is used to specifiy the class from which the RPC server objects are created, if something other than Apache::RPC::Server. If this information is passed via the "serverclass" parameter to the new method above, that value overrides any value here. However, that requires actually creating an object to use as the handler, whereas this handler may be used directly, as a static handler. It would be configured outside of any <Location> blocks, a requirement for the PerlChildInitHandler phase. It is designed to stack cleanly with any other handlers for that phase, provided your mod_perl installation supports stacked handlers.

Additional Methods

version

(May be called as a static method.) Returns the current version of this module.

apache_status_attach

Attach the Apache::RPC::Status module to the main screen of the Apache::Status display.

default_object

(May be called as a static method.) Returns a default Apache::RPC::Status instance when called as a static method. Returns the calling reference itself, otherwise.

header(REQUEST, TITLE)

Produces the HTML header for a page. Uses the passed-in title parameter to give the page a title, and extracts any request-specific information from the Apache request object passed as the first parameter.

footer(REQUEST)

Produces the HTML footer.

make_url(QUERY|REQUEST, FLAG)

(May be called as a static method.) This creates a URL string for use as a hyperlink. It makes certain to preserve all parameters in a CGI-like fashion. Additionally, it can make the URL in such a fashion as to allow better integration with the Apache::Status package. If the "FLAG" parameter is passed and is any true value, then the resulting URL will be tailored for use with Apache::Status. The first argument must be either the original request object as passed by mod_perl, or a reference to a CGI object created from the request (see CGI for more on the CGI class).

main_screen(REQUEST, QUERY, INTERNAL)

Renders the HTML (minus the header and footer) for the main screen. The arguments are the Apache request object, a CGI query object created from the request, and a boolean flag indicating whether the call into this method was made from within this module or made from the Apache::Status page.

server_summary(SERVER)

Creates an HTML snippet to provide a summary for the server passed in as an argument. The passed-in value should be the server object, not the name.

server_detail(REQUEST, QUERY, INTERNAL)

Renders the HTML (minus header and footer) for a screen describing a server instance in detail. The server is specified by name in the query parameters. The arguments are the same as for "main_screen".

method_summary(SERVER, METHOD, BASEURL)

Creates and HTML snippet to provide a summary for the specified method of the specified server. The third argument is a base-URL to use for making links to the detailed method page.

method_detail(REQUEST, QUERY, INTERNAL)

Renders the HTML (minus header and footer) for a screen describing a method on a specific server instance, in detail. The method and server are specified by name in the query parameters. The arguments are the same as for "main_screen".

Use and Extension Within Perl Sections

Adding a new screen means writing a routine to handle the requests, and then adding a hook into that routine to the object that is the handler for the Apache location that serves RPC status requests. The routines that are written to handle a request should expect four arguments (in order):

The object reference for the location handler

The Apache request object reference

A query object reference (see below)

A flag that is only passed when called from Apache::Status

The routines are given both the original request object and a query object reference for sake of ease. The query object is already available prior to the dispatch, so there is no reason to have each hook routine write the same few lines to derive a query object from an Apache request. At the same time, the hooks themselves may need the Apache object to call methods on. The query object is an instance of CGI. The flag parameter is passed by the linkage from this status package to Apache::Status. The primary use for it is to pass to routines such as make_url that are sensitive to the Apache::Status context.

The return value from these routines must be a reference to a list of lines of text. It is passed to the print method of the Apache class. This is necessary for compatibility with the Apache::Status environment.

To add a new hook, merely assign it to the object directly. The key is the value of the "screen" parameter defined above, and the value is a hash reference with two keys:

title

A string that is incorporated into the HTML title for the page.

call

A reference to a subroutine or closure that implements the hook, and conforms to the conventions described above.

A sample addition:

    $stat_obj->{dbi} = {
                           title => 'RPC-side DBI Pool',
                           call  => \&show_dbi_pool
                       };