[C2] Status and profiling.

[Paul Russell <pa...@luminas.co.uk>]

Hi All,

I've been beavering away over the last few hours on a new version
of the StatusGenerator for C2. I've tried to build some architecture
to allow the administrator to drill down into the depths of the
system to see what's going on.

Basically, this revolves around a set of interfaces which
components can implement which allow them to report their
status to the framework. This all works fine until I get into
the generated sitemap code, because when we get to that level,
we start to loose our higherachy of componenets in favour of a
(potentially faster) linear translation of the sitemap semantics.

My first attempt at tackling this was to create a secondary
tree of components which mirrored the sitemap configuration,
and queried the components as and when. This hit problems because
it's currently very difficult to query the actual components
used during requests, because they currently have a short life-
time (pending us moving to the new Avalon interfaces).

What I'm pondering is that we could use a framework of component
managers (well, proxys really) to build up a higherachy of components
to fire requests at. Do you guys think this would be too much of
a performance hit? When we move to the new Avalon interfaces, we
need to be able to manage pools of components as well as recognising
threadsafe components etc. Using proxies, we can delegate this
task to the proxy and let the sitemap be relatively simple.

Consider the following:

public interface SitemapComponentProxy extends Component, Configurable {
	/** Process the given request.
	 * @return <code>true</code> if the request was processed
	 * 	successfully, <code>false</code> otherwise.
	 */
	public boolean process(Environment env) {

	}

	/** Add child proxies to this SitemapComponentProxy.
	 */
	public void addChild(SitemapComponentProxy child);
}

public interface MatcherProxy extends SitemapComponentProxy, Matcher {
}

public class DefaultMatcherProxy implements MatcherProxy {
	/** Construct a new DefaultMatcherProxy.
	 * @throws InvalidComponentException when the specified
	 * 	class is not an <code>instanceof</code> Matcher.
	 */
	public DefaultMatcherProxy(Class matcherClass)
		throws InvalidComponentException;

	// Implementation of other methods from implemented interfaces
	// (including setConfiguration, which should be stored and used
	// to configure components when they are instantiated.)
}

We could then use java/sitemap.xsl to generate a hierachy of
(persistant) proxies when the sitemap is instantiated by
sitemap.Handler. When a request comes in, it could be passed to
the <code>PipelineProxy</code>s' process method, which then passes
it on down the hierachy as normal. When the request got to a
component such as a matcher where there really is a component
to talk to, the proxy can interrogate the component's Class and
decide whether to instantiate a new copy, fire the request straight
through a ThreadSafe copy, grab a new Poolable component from the
pool or whatever. If the matcher matches processing continues
with the matcher's children, otherwise the matcher returns false
and the pipeline continues with its next child.

Advantages:

 * potentially simpler handling of new Avalon marker interfaces.
 * sitemap generator *should* be simpler.
 * status and profiling made considerably easier (profiling is
   even more of a nightmare than status without proxies because
   you need to maintain profiling info between requests even though
   the component itself is now defunct).
 * Anything else you can think of(?)

Disadvantages:

 * Speed. (lots of non static method calls instead of a nice
   run of bytecode for the optimiser).
 * Lots of work (fair bit of coding to be done to make it work - happy
   to help there though, obviously).
 * Anything else you can think of(?)

If anyone's got any other intreguing ideas for making the status
thing work under the current architecture, and in particular handling
profiling etc, that'd be great.

Comments/flames on the back of an asbestos coated postcard to
cocoon-dev@... ;)


Paul

P.S. excuse the dodgy english - in a hurry!
-- 
Paul Russell                               <pa...@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.