[cocoon3 profiling] Concept

[Andreas Pinter <e0...@student.tuwien.ac.at>]

Hello there,

We are going to send our first major patch. We are aware of the fact,
that our communication to the community was rather small up until now.

So I'll try to explain our current concept:

cocoon-profiling is a tool to determine how long the execution of a
request/pipeline took. It will show the specific times of every
component, so it should be very useful for debugging complex
applications.  We do not profile any memory usage.

This subproject is split into two components: cocoon-profiling is the
"backend" which does all the profiling work; cocoon-profiling-firebug is a
extension for firebug (a debugging/dev tool for firefox) to display the
information to the user.  It is written in JavaScript.

Our backend is based on (Spring-)AOP to keep the impact on the cocoon code
low. The next paragraphs give a more detailed introduction on how cocoon 
profiling works.

We'll start with the explanation of our three
aspects, which try to intercept every "interesting" cocoon method 
invocation.
These focus on the main parts of cocoon:
- ServletProfilingApsect           captures every invocation of Servlet
- SitemapNodeProfilingAspect       same for every SitemapNode
- PipelineComponentProfilingAspect and for every PipelineComponent

Every Aspect has an instance of an InvocationDispatcher.  The aspect
just forwards the method invocation information to its dispatcher.

At this point I need to say something about the distribution in the
background: As you can see in the application context
(cocoon-profiling-component.xml) each dispatcher owns a so-called
default profiler. A dispacher can hold a bunch of (specific / custom)
profilers, which can be added by the user.  This means that you can e.g.
add a profiler for HttpServlet which captures more information than the
default Servlet profiler.

Back to the process: Our Dispatcher now chooses the most specific
profiler and calls its "before" method. After this the catched method is
processed (so we let Cocoon3 do its work) and afterwards the Dispatcher
calls the profiler.after() method or the profiler.exception() -
depending on the result of the method invocation.  We pass a new
instance of ProfilingData to these methods.  A profiler can add
information about what happened to this instance.

At this point of the process we have collected all the data, but not
saved it.  So inside the "after" method, we pass the ProfilingData to
the ProfilingDataManager. This class sorts the ProfilingData depending
on their invocation level (based on the time / place of the profiler
call) and builds a tree of ProfilingData objects, which is maintained by
the profiler.

When the DataManger notices that it just got to the last ProfilingData
it passes the information to the ProfilingDataHolder, which is just a
simple map of String (which is the profiling id) and data.

At this point of the process, the cocoon work is done and the user sees
his result in the browser. This result hasn't changed in any way from a
call without profiling (it may have took a little bit longer, of course
  ;)  except from an additional HTTPResponseHeader information. We insert
the aforementioned profiling id in the special X-Cocoon-Profiling-ID
header.

This ID is used by the Firebug plugin to start a new request to a
specific profiling-pipeline.  The pipeline gets the ProfilingData
information using the DataHolder and generates XML with a SAX generator
and a xml serializer. If you don't like firebug you could process this
XML in your own tool to display profiling information.

So how does the plugin work?  First of all it is important to know, that
our Firebug plugin attaches itself to the Net-Tab of Firebug. (If you
don't know what I'm speaking about, try to use the 1.4X Version of
Firebug - the X is no typo) Via the Net-Tab we are informed about a
finished response, which we scan for the above mentioned
X-Cocoon-Profiling-ID. If we find this ID we take it and do our own
"hidden" request for ProfilingData. The response of this request is
processed by the Firebug plugin and builds a TreeView out of the
returned XML file.

The next steps for the whole process will be to produce a XMLSchema file
for the presented XML data, so we can make the plugin work better,
because it's not just a stupid XML-TreeView-Explorer any more.  On the
other hand we try to move the Cocoon-Profiling-Tab into the NetTab to
keep track of different Requests/Responses.

If you have any questions or suggestions, please feel free to share.  We
really need some feedback to see if we are going in the right direction.

Greetings,
Andreas