Web-based log4j configuration

Usually a reconfiguration of log4j requires an application restart. That’s annoying, particularly if it is necessary to track what an application is doing in a production environment. It would be nice to be able to change logging levels without having to re-deploy the application.

So I created a Viewlet that allows the user to reconfigure log4j logging levels of a running InfoGrid application from the web browser. Screen shot to the right. Nothing particularly fancy, but useful. Obviously, you can set any access control for it that you like in the application’s ViewletFactory.

The Viewlet has been added to MeshWorld and NetMeshWorld in trunk. The code is in a new project called org.infogrid.jee.viewlet.log4j.

Tracking XPRISO Messages

XPRISO is the messaging protocol used by InfoGrid to keep distributed information consistent. The acronym stands for “eXtensible Protocol for the Replication, Integration and Synchronization of distributed Objects”.

The current version of InfoGrid uses XPRISO mostly for communication between an application’s main NetMeshBase, and the ShadowMeshBases that track (“shadow”) external data feeds.

Sometimes it is really useful to track XPRISO messages.The simplest way o track all XPRISO messages in your application is this:

  1. Determine the classes that your application instantiates that implement the NetMeshBases communicating via XPRISO. For example, that might be org.infogrid.meshbase.net.local.m.LocalNetMMeshBase and org.infogrid.probe.shadow.m.MShadowMeshBase, or perhaps org.infogrid.meshbase.net.local.store.IterableLocalNetStoreMeshBase and org.infogrid.probe.shadow.store.StoreShadowMeshBase.
  2. Set their logging level to INFO.

This might be as simple as adding the following two lines to your Log.properties file:

log4j.category.org.infogrid.meshbase.net.local.store.IterableLocalNetStoreMeshBase=INFO
log4j.category.org.infogrid.probe.shadow.store.StoreShadowMeshBase=INFO

Voilá, all XPRISO messages are written to your logger. (Some detail is omitted to make the log readable.)

Here is an actual example:

INFO  2009-10-12 15:32:14,992 [pool-1-thread-1] shadow.store.StoreShadowMeshBase (Log4jLog.java:152)
 @ org.infogrid.util.logging.log4j.Log4jLog.logInfo:152
 - org.infogrid.meshbase.net.xpriso.SimpleXprisoMessage@5baec83c{
    route: http://localhost:8085/app1/ -> http://localhost:8085/app2/, requestId: 1255386734969
    requestedFirstTime:
        #http://localhost:8085/app2/
}

INFO  2009-10-12 15:32:15,018 [pool-1-thread-2] local.store.IterableLocalNetStoreMeshBase (Log4jLog.java:152)
@ org.infogrid.util.logging.log4j.Log4jLog.logInfo:152
 - org.infogrid.meshbase.net.xpriso.ParserFriendlyXprisoMessage@4e940b1e{
    route: http://localhost:8085/app2/ -> http://localhost:8085/app1/, responseId: 1255386734969
    conveyedMeshObjects:
        id: http://localhost:8085/app2/
}

Here, the first NetMeshBase asked the second for an object, and promptly got a replica in return.

If you don’t like the logging format, or want to log them differently, you can use your own XprisoMessageLogger simply by invoking setXprisoMessageLogger on the NetMeshBase whose messages you like to track.