Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <20000322232033.41212.qmail@hotmail.com>
From: "Robin Green" <greenrd@hotmail.com>
To: cocoon-dev@xml.apache.org
Subject: Re: Plan for Pipeline Logging
Date: Wed, 22 Mar 2000 23:20:33 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed

Next time I will wait for a reply from committers before doing major reorgs 
of the code :(

Stefano wrote:
>
>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.

Okay, call it pipeline tracing?

>
>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.

But I thought you didn't like PIs? ;) only kidding

Actually what I thought was adding one or two lines to cocoon.properties or 
the command line, e.g.

pipeline.trace=*

or

pipeline.trace=/myapp/test.xml
pipeline.trace=/myapp/another.xml

would be simplest. Obviously this would be commented out in the 
distribution!

I have about 3 or 4 steps in a certain pipeline (yes I know it may be a 
crazy design) so putting in PIs would be a pain and might even risk changing 
the behaviour I was trying to debug. (Postprocessing after XSP-transform 
requires <xsl:processing-instruction> tag etc., right? - or is there a 
simpler way?) Properties are easier for the user.

Also I might put in a simple XSP page to turn on tracing when fetched (to 
avoid restarting webserver). Anything that obviates need to restart is good 
- I really appreciate the dynamic code reloading BTW! Users would be 
strongly advised in the comments to secure or deny access to this page to 
prevent DOS attacks.

> > 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.

Okay don't flame me I'm a newbie! ;)

But why?

Let me guess, "if it ain't broke, don't fix it".  [ ain't == isn't ]

That's sensible to an extent. But you are doing lots of rewriting for C2 
(right?) so maybe these reorgs I suggested could be done in C2?

Reasons for suggestions: (obvious? Sorry, I'm not trying to be 
patronising!!)

> > 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.

Reason: If the code is just copied and pasted, creating redundancy, that's 
bad news because changes may need to be applied N times (as you know). If 
instead I call code in processor.xsp package, that's a confusing 
organisation because what I'm doing (tracing) is not a specifically XSP 
operation (it would be done for _every_ stage in the pipeline). Better to 
separate out the code which is not really specifically XSP code.

> > Also moving
> > some of the IO util methods to org.apache.cocoon.IOUtils, just for 
>tidyness.

Again, they are not specifically XSP. I need to call them (or copy them, 
which is worse, so I won't), but it is confusing to call them if they are in 
the XSP package, because they are not specifically XSP operations.

I'm not dissing your work here, Stefano. The work you've done on C1.7.1 is 
impressively well-organised as far as I can see (but I'm a newbie to code 
_design_ so who am I to judge?). These are comparatively trivial quibbles.

Okay, the changes I made were widespread (bad) but they at least cleaned up 
the code a little bit and made it a bit easier to understand. (I'll post 
them soon.)

Not to make a mountain out of a molehill - but any chance of ever committing 
these changes, do you think? In C2 maybe?

>
> > 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.

Will consider implementing Processor, but still need to put hooks into the 
engine to avoid having to manually insert/generate PIs every time I need to 
do a trace.

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

That's what I plan to do - but performance is not going to die! It would be 
like this:

if (tracingEnabled) {
  /* flag tracingEnabled is set by PipelineTrace.init(Configurations) */
  dotrace (...);
}

You can't tell me that's going to be a noticeable slowdown, if the user 
hasn't turned on tracing! Only one if statement! <:-)

--
Robin

P.S. I haven't read much of ESR - does anyone know if he talks about 
disagreements in OSS projects? Have a link? It would be interesting to know 
how he deals with them (I think I can guess - I've seen his flames ... ;-)

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