Plan for Pipeline Logging

[Robin Green <gr...@hotmail.com>]

I would like to have a look at the intermediate result trees generated 
during the Cocoon processing pipeline (and even just the output tree, since 
my pages are generating a malformed meta refresh tag, so I can't even see 
the result page in IE!) for debugging purposes, so I am working on a new 
logger level, "pipeline", which will log each intermediate result tree to a 
separate file in the repository (probably calling them foo$1.xml, foo$2.xml 
etc). Of course the Xalan command-line executor can be used for simple 
debugging, but if XSP or request parameters are involved, it's best to debug 
in Cocoon directly.

I plan to encapsulate the Repository code in a very small class 
org.apache.cocoon.store.repository.Repository since it will be used by both 
XSP and the pipeline logger, and to change the property name from 
"processor.xsp.repository" to "repository.dir" (keeping the comments 
attached) since it will no longer be just about XSP necessarily. Also moving 
some of the IO util methods to org.apache.cocoon.IOUtils, just for tidyness.

Does this sound okay or am I stepping on any toes?

P.S. This is Cocoon-1.7.1dev I am talking about here.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Re: Plan for Pipeline Logging

[Stefano Mazzocchi <st...@apache.org>]

Robin Green wrote:
> 
> I would like to have a look at the intermediate result trees generated
> during the Cocoon processing pipeline (and even just the output tree, since
> my pages are generating a malformed meta refresh tag, so I can't even see
> the result page in IE!) for debugging purposes, so I am working on a new
> logger level, "pipeline", which will log each intermediate result tree to a
> separate file in the repository (probably calling them foo$1.xml, foo$2.xml
> etc). Of course the Xalan command-line executor can be used for simple
> debugging, but if XSP or request parameters are involved, it's best to debug
> in Cocoon directly.

Don't! This is not logging.

I'd suggest you to write a processor instead: doesn't change what passes
thru, but serializes the resuls on the side. So you can place that as PI
and make them executed without impacting everybody else's performance.
 
> I plan to encapsulate the Repository code in a very small class
> org.apache.cocoon.store.repository.Repository since it will be used by both
> XSP and the pipeline logger, and to change the property name from
> "processor.xsp.repository" to "repository.dir" (keeping the comments
> attached) since it will no longer be just about XSP necessarily. Also moving
> some of the IO util methods to org.apache.cocoon.IOUtils, just for tidyness.

Hmmm, I don't like that.
 
> Does this sound okay or am I stepping on any toes?

I believe that using "debugging" non-modifying components (as
processors/filters) to build your pipelines is the cleanest way to do
it. another useful debugging component would be the "validator" that
validates the document and logs validating problems.

But I'm way open to suggestions... just don't place your debugging hooks
into the cocoon engine or performance would die.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------