cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: stderr and stdout -> browser
Date Fri, 17 Nov 2000 13:44:41 GMT


On Thu, 16 Nov 2000, Robin Green wrote:

> Jeff Turner <jeff@socialchange.net.au> wrote:
> > > Jeff Turner <jeff@socialchange.net.au> wrote:
> > > >Poking around in Engine.java, I see there's a "debug" parameter which
> > > >redirects stderr and stdout to the browser. Great! Could the existence

> >of
> > > >this be added to the documentation?
> > >
> > > First it needs fixing. Looking at the code it doesn't seem to turn off 
> >once
> > > you turn it on.
> > >
> > > But it's a useful idea. Let's define requirements for this. Should it 
> >appear
> > > alongside the normal output, or instead of it? Isn't this a bit of a
> > > security risk, allowing any user to see the logs - so shouldn't it be
> > > disabled by default in the distribution?
> > >
> > > If alongside, where? How can you integrate it into the page when Engine
> > > doesn't know at the start whether the output will be HTML, WML, XML, PDF 
> >or
> > > what - and different output methods would be needed for different output
> > > formats?
> >
> >Is this meant to be a Grand Unified Debugging Architecture, or just a
> >useful hack?
> 
> A hack.
> 
> >Is there a G.U.D.A. planned for C2?
> 
> Well there's Avalon logging, which is cool. (Also note, a future JDK will 
> include a logging API as standard, according to the Java Community Process 
> website.)

Are we talking about logging for Cocoon or XSP pages? For Cocoon, use of
*any* log API would be nice ;)

For XSP pages, there's all sorts of logging APIs: Avalon, log4j, Sun
vapourware ;) etc. There's nothing inherent in XSP that forbids the use of
any API.

For instance, here's an XSP page using log4j (my favourite!):

<?cocoon-process type="xsp"?>
<xsp:page language="java" xmlns:xsp="http://www.apache.org/1999/XSP/Core">
 <xsp:logic>
  org.log4j.Category CAT = org.log4j.Category.getInstance("MyCategory");
 </xsp:logic>

 <html>
  <p>Hello world</p>
  <xsp:logic>CAT.debug("This is a debug-level log");</xsp:logic>
  <xsp:logic>CAT.info("This is an info-level log");</xsp:logic>
  <xsp:logic>CAT.error("This is an error-level log");</xsp:logic>
 </html>
</xsp:page>


And here's the output (the format is customisable):


0 DEBUG [Thread-10]  MyCategory#populateDocument (_testlog4j.java:77) -
This is a debug-level log
335 INFO  [Thread-10]  MyCategory#populateDocument (_testlog4j.java:81) -
This is an info-level log
465 ERROR [Thread-10]  MyCategory#populateDocument (_testlog4j.java:85) -
This is an error-level log


(note the line numbers.. can Avalon do that? ;)

Of course, one can easily create a logging taglib to simplify things.

So basically I'm saying a Grand Unified Debugging Architecture for XSPs is
unneeded, since regular APIs do the job. Of course, a Grand Unified
Debugging Taglib is an interesting possibility..

> 
> >To meet the needs of the majority of developers, how about:
> >
> >  - assume HTML output
> 
> Yes, if formatter is html or xhtml, just put it inside <html><body>, just

> before the Formatter is called, or if there is no such structure because 
> maybe the user is commenting out their stylesheet, inside the root element.
> 
> Actually, other formats e.g. PDF could be taken care of by the following 
> approach:
> 
> In the xml file:
> 
> <my-debug-tag><util:debug-dump></my-debug-tag>
> 
> (this is too trivial to add to the xsp core namespace, it's just a matter of 
> <xsp:expr>debugBuffer.toString ()</xsp:expr>).

Okay, how do you get data into debugBuffer? Perhaps:

<util:debug> A debug message </util:debug>

> 
> In the xsl file:
> 
> <xsl:value-of select="my-debug-tag">
> <!-- put it in an appropriate place in the output -->
> 
> >  - leave debug text inline
> 
> What do you mean by that?

Oh.. I was thinking that debug output would just be another Element in the
produced DOM tree. It would be "inline", interspersed with regular output.
The only difference with a regular Element is that this one is only
included in the generated DOM if "debug" is true.

--Jeff


> >  - define a flag in cocoon.properties for *enabling* the debug parameter
> 
> Agreed.
> 
> 
> 
> 
> _____________________________________________________________________________________
> Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 


Mime
View raw message