tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Everman <ever...@precedadesign.com>
Subject IMonitor Enhancement
Date Thu, 05 Jun 2003 18:46:08 GMT
Its been a while since IMonitor has been discussed on the list - I noticed 
that Howard had mentioned it as an open issue for the 3.0 release so I 
thought I would resurrect the issue for discussion.

I created an RFE at http://issues.apache.org/bugzilla/show_bug.cgi?id=18379

I believe IMonitor was initially designed as a simple debug tool that could 
logs Strings describing individual requests as they happened.  However, the 
IMonitor interface occupies a niche that is hard to match with any other 
API in Tapestry - it provides one pluggable API that is aware of the entire 
request process.  For persistence layers, this has allowed many of us to 
use IMonitor to close/commit/rolled back transactions when a request 
completes.  Another potential use would be authorization of requests at an 
application level (rather then page by page).

But there are problems.  While IMonitor is notified of events during the 
request cycle, it is not given any context - it is simply notified that a 
certain event happened to an unspecified request.  A typical method 
signature looks like this:


public void serviceEnd(String serviceName);

To get around this, we have been creating IMonitor subclasses that accept 
more info then just a String and Engine subclasses that know how to use 
them.  At this point, however, IMonitor is no longer plugable.

The first step towards making IMonitor more usable is to pass the current 
IRequestCycle for every event - this would give IMonitor its needed 
context.  Secondly, I would like to see an 'End' event for every 'Begin' 
event - right now there are two missing.  Finally, last I looked at the 
code, the serviceEnd event was not guaranteed to be called if there was an 
exception.

One additional (really nice by optional) feature would be to split the 
interface into three:  IServiceMonitor, IPageMonitor, 
ISessionMonitor.  While this would add complexity to the Engine, it would 
allow developers to write very targeted code with scope that matches the 
entity being monitored.  For instance, a PageMonitor would allow you to be 
notified of each page as it loads, do initialization work, log the access, 
create resources and place them in the request, store local values in the 
PageMonitor, and deallocate everything when that page completes.  A 
SessionMonitor would allow you to do the same thing at the session level - 
a SessionMonitor would have a life time of one session.

So that's my suggestion for IMonitor.  Discuss?


Eric Everman

Preceda Design LLC
www.precedadesign.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message