avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [RT] Component Tracking and Environment Exposure
Date Tue, 16 Oct 2001 09:14:28 GMT

Kool discussion. I actually had to stop and think a few times ;)

On Mon, 15 Oct 2001 23:37, Berin Loritsch wrote:
> * State Trace: Tracks the object states or data states in a component.
> * Event Trace: Records the events and sequences occuring in a component.

In a lot of ways I see events and states as two sides of the one coin. Events 
could essentially be classified as either notifications or transitions to 
another state. Would you agree with that? 

> Part of the reason I meantioned AspectJ is that it can do the Operational
> tracing for Components we have no control over.  By adding a tracking
> package to Framework, and an interface for a Tracer object, we can have
> another project work on the Tracer implementation.  That way the mechanism
> to proliferate the tracing methods is a completely separate concern.
> We do have to manage how it is plugged in, but that is a later concern.

Perhaps. AspectJ is a really kool toolkit but I fear the added complexity it 
will bring. 

> > It is definetly something that we should be doing. However I believe it
> > should be built on JMX> While JMX may not be the most elegant API, it is
> > a standard and for 99% of time it is good-enough. (And I think we can get
> > around the licensing issues by reusing parts of enhydra).
> Keep in mind that we want to expose the ability to Component writers.  The
> Tracer implemented in Phoenix should most definitely be implemented with
> JMX. Especially since we started the work with it already.  However, there
> are different clients with different needs.  For example, Cocoon would like
> a mechanism so that when someone goes to the Cocoon Status page, they would
> like to have cache sizes and pool sizes included.  With a generic Tracer
> interface, Cocoon can have a Tracer implementation that feeds the
> StatusGenerator with the information it want's to expose.  It would even
> be able to add in performance data to find bottlenecks.

I can't see how you would not want to use JMX inside Cocoon. StatusGenerator 
roughly corresponds to the notion of an agent, albeit it would probably be 
specialized for cocoon specific data. It would be simple to have the various 
Cocoon components exposed as MBeans.



For every complex problem there is a solution that 
is simple, neat and wrong

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message