You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2004/01/12 07:38:24 UTC
Cocoon Stack Traces
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
stack trace produces a poor result. Although location information is
available it isn't provided according to a consistent model. Rhino
stores a JS stack trace in a JavaScriptException. JXTemplateGenerator
stores its execution stack trace in a sequence of nested
SAXParseExceptions. The Sitemap processor currently doesn't seem to
produce an execution stack trace, but ProcessingNode's have location
information so it should be possible. In addition,
javax.xml.transform.TransformerException has location information.
o.a.c.ProcessingException gives special treatment to SAXParseException
and TransformerException and adds location information to its own stack
trace (but only for one level - it doesn't included nested
SAXParseException's, for example). There seem to be various other hacks
to attempt to include location information in the exception message or
stack trace.
The idea is to allow a Cocoon processing element that operates on source
code (sitemap, flowscript, jxtemplate, etc...) to provide location
information about the execution stack of that processing element when
the exception occurred (see also
http://marc.theaimsgroup.com/?t=105597249800001&r=1&w=2).
To accomplish this I chose not to use the JVM exception stack trace but
instead to store a "Cocoon" stack trace in the current object model. I
added the following to the class o.a.c.Cocoon:
public class Cocoon {
....
public interface StackTraceElement {
public String getComponent();
public String getMessage();
public String getMethod();
public String getURI();
public int getLineNumber();
public int getColumnNumber();
}
public static void addCocoonStackTrace(
Map objectModel,
String message,
String component,
String method,
String uri,
int lineNumber,
int columnNumber);
public static ArrayList /* of StackTraceElement */ getStackTrace(Map
objectModel)
}
I added calls to addCocoonStackTrace() in JXTemplateGenerator,
FOM_JavaScriptInterpreter, and in MountNode.java and CallNode.java.
With a method like the following:
private static void dumpStackTrace(Map objectModel) {
ArrayList stackTrace = Cocoon.getStackTrace(objectModel);
for (int i = 0, len = stackTrace.size(); i < len; i++) {
StackTraceElement e = (StackTraceElement)stackTrace.get(i);
String component = e.getComponent();
String message = e.getMessage();
String method = e.getMethod();
String uri = e.getURI();
int lineNum = e.getLineNumber();
int colNum = e.getColumnNumber();
String out = component + ": ";
if (message != null) {
out += message;
out += " ";
}
out += "(";
if (method != null) {
out += method + " ";
}
out += "at " + uri;
if (lineNum > 0) {
out += ", Line " + lineNum;
if (colNum >= 0) {
out += "." + colNum;
}
}
out += ")";
System.out.println(out);
}
}
I was able to produce the following output:
jxtemplate: No pointer for xpath: $blah (at
file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/screens/getNumberA.xml,
Line 26.13)
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
flowscript: (at
resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js,
Line 4)
flowscript: (getNumber at
file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js, Line 31)
flowscript: (calculator at
file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js, Line 11)
sitemap: (call at
file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/sitemap.xmap:48:42)
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
It seems straightforward to hook this into Cocoon's error reporter.
WDYT?
In the process of doing this, however, I found that pipeline processing
doesn't actually occur during sendPage*(). Instead, it simply sets a
flag to redirect to the passed uri and returns. Pipeline processing
actually occurs after the flowscript has completed. This is also a
problem for the solution proposed here to release components after
pipeline processing:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107360524206262&w=2.
To solve both problems I modified the implementation of sendPage*() to
call the sitemap processor recursively instead. It seems to work. Does
anyone know of a problem with this approach?
Regards,
Chris
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Jan 2004, at 07:38, Christopher Oliver wrote:
> I started looking into how I could get a meaningful stack trace (with
> location information) spanning (possibly nested) invocations of the
> sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
> stack trace produces a poor result. Although location information is
> available it isn't provided according to a consistent model. Rhino
> stores a JS stack trace in a JavaScriptException. JXTemplateGenerator
> stores its execution stack trace in a sequence of nested
> SAXParseExceptions. The Sitemap processor currently doesn't seem to
> produce an execution stack trace, but ProcessingNode's have location
> information so it should be possible. In addition,
> javax.xml.transform.TransformerException has location information.
> o.a.c.ProcessingException gives special treatment to SAXParseException
> and TransformerException and adds location information to its own
> stack trace (but only for one level - it doesn't included nested
> SAXParseException's, for example). There seem to be various other
> hacks to attempt to include location information in the exception
> message or stack trace.
>
> The idea is to allow a Cocoon processing element that operates on
> source code (sitemap, flowscript, jxtemplate, etc...) to provide
> location information about the execution stack of that processing
> element when the exception occurred (see also
> http://marc.theaimsgroup.com/?t=105597249800001&r=1&w=2).
>
> To accomplish this I chose not to use the JVM exception stack trace
> but instead to store a "Cocoon" stack trace in the current object
> model. I added the following to the class o.a.c.Cocoon:
>
> public class Cocoon {
> ....
> public interface StackTraceElement {
> public String getComponent();
> public String getMessage();
> public String getMethod();
> public String getURI();
> public int getLineNumber();
> public int getColumnNumber();
> }
>
> public static void addCocoonStackTrace(
> Map objectModel,
> String message,
> String component,
> String method,
> String uri,
> int lineNumber,
> int columnNumber);
> public static ArrayList /* of StackTraceElement */
> getStackTrace(Map objectModel)
>
> }
>
> I added calls to addCocoonStackTrace() in JXTemplateGenerator,
> FOM_JavaScriptInterpreter, and in MountNode.java and CallNode.java.
>
> With a method like the following:
>
> private static void dumpStackTrace(Map objectModel) {
> ArrayList stackTrace = Cocoon.getStackTrace(objectModel);
> for (int i = 0, len = stackTrace.size(); i < len; i++) {
> StackTraceElement e = (StackTraceElement)stackTrace.get(i);
> String component = e.getComponent();
> String message = e.getMessage();
> String method = e.getMethod();
> String uri = e.getURI();
> int lineNum = e.getLineNumber();
> int colNum = e.getColumnNumber();
> String out = component + ": ";
> if (message != null) {
> out += message;
> out += " ";
> }
> out += "(";
> if (method != null) {
> out += method + " ";
> }
> out += "at " + uri;
> if (lineNum > 0) {
> out += ", Line " + lineNum;
> if (colNum >= 0) {
> out += "." + colNum;
> }
> }
> out += ")";
> System.out.println(out);
> }
> }
>
> I was able to produce the following output:
>
> jxtemplate: No pointer for xpath: $blah (at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/screens/
> getNumberA.xml, Line 26.13)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
> sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
> flowscript: (at
> resource://org/apache/cocoon/components/flow/javascript/fom/
> fom_system.js, Line 4)
> flowscript: (getNumber at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js,
> Line 31)
> flowscript: (calculator at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js,
> Line 11)
> sitemap: (call at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/sitemap.xmap:48:42)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
> sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
>
> It seems straightforward to hook this into Cocoon's error reporter.
>
> WDYT?
I love it!
did I mention you are my hero? ;-)
--
Stefano.
Re: Cocoon Stack Traces
Posted by bernhard huber <be...@gmx.at>.
hi,
<snip/>
Great idea, i was thinking about doing some sort of sitemap debugging,
please keep in mind that output is not solely system.out but some sort
of UI,
perhaps to give some idea, the servlet, or command line might be replaced by
ui
see
http://meineseite.one.at/bh22351/cocoonbean-3.png,
or http://meineseite.one.at/bh22351/cocoonbean-1.png, and
http://meineseite.one.at/bh22351/cocoonbean-2.png
anyway great idea!
> I was able to produce the following output:
>
> jxtemplate: No pointer for xpath: $blah (at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/screens/getNumberA.xml,
> Line 26.13)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
> sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
> flowscript: (at
> resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js,
>
> Line 4)
> flowscript: (getNumber at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js, Line
> 31)
> flowscript: (calculator at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js, Line
> 11)
...
<snip/>
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
Re: Cocoon Stack Traces
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Vadim Gritsenko dijo:
> Christopher Oliver wrote:
>> Sylvain Wallez wrote:
>>
>>> - we need a "popStackFrame()" method, since once a component has been
>>> executed successfully and execution continues in its following
>>> siblings, it should no longer appear in the stack trace
>>
>>
>> The idea is that this stack trace is created during exception
>> processing:
>>
>> try {
>> do whatever
>> } catch (Exception e) {
>> Cocoon.addCocoonStackTrace("failed to do whatever", "comp",
>> "method", uri, line, column);
>> throw e;
>> }
>>
>> Thus, during normal processing there is no overhead. That's why
>> there's no popStackFrame().
>
> HUGE +1 to no overhead. And, if it helps, my thinking on adding traces
> to TreeProcessor was among the same lines with one difference: I thought
> we can store this stacktrace in the exception itself. What do you think?
Another BIG +1 The idea to store it inside the exception is great!
Best Regards,
Antonio Gallardo
Re: Cocoon Stack Traces
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> - we need a "popStackFrame()" method, since once a component has been
>> executed successfully and execution continues in its following
>> siblings, it should no longer appear in the stack trace
>
>
> The idea is that this stack trace is created during exception processing:
>
> try {
> do whatever
> } catch (Exception e) {
> Cocoon.addCocoonStackTrace("failed to do whatever", "comp",
> "method", uri, line, column);
> throw e;
> }
>
> Thus, during normal processing there is no overhead. That's why
> there's no popStackFrame().
HUGE +1 to no overhead. And, if it helps, my thinking on adding traces
to TreeProcessor was among the same lines with one difference: I thought
we can store this stacktrace in the exception itself. What do you think?
Vadim
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Jan 2004, at 16:35, Christopher Oliver wrote:
>
> Sylvain Wallez wrote:
>
>> Christopher Oliver wrote:
>>
>>> I started looking into how I could get a meaningful stack trace
>>> (with location information) spanning (possibly nested) invocations
>>> of the sitemap, flowscript, and JXTemplateGenerator.
>>
>> <snip>
>>
>>>
>>> WDYT?
>>
>>
>>
>> /me thinks it's great!
>>
>> Some low-level remarks, however:
>>
>> - we need a "popStackFrame()" method, since once a component has been
>> executed successfully and execution continues in its following
>> siblings, it should no longer appear in the stack trace
>
> The idea is that this stack trace is created during exception
> processing:
>
> try {
> do whatever
> } catch (Exception e) {
> Cocoon.addCocoonStackTrace("failed to do whatever", "comp",
> "method", uri, line, column);
> throw e;
> }
>
> Thus, during normal processing there is no overhead. That's why
> there's no popStackFrame().
I like this approach.
>> - is the "message" parameter really needed? It's only meaningful for
>> the statement where the error occured, and will be present in the
>> Java exception that is raised.
>
> I guess you're right, but my thinking was that additional information
> about the call site could be useful. If there's no additional
> information you can just pass null.
There might be cases where from a SAXException it could look like a
"element could get a closing tag" while from a sitemap perspective it
could look like "xml document is not wellformed".
Having a bigger context could yield more semantically meaningful error
messages and this is very valuable IMO.
--
Stefano.
Re: Cocoon Stack Traces
Posted by Nicolas Toper <nt...@jouve.fr>.
Hi,
I'm a cocoon users, and I agree: a general debugger would be cool; but we can
live without it. Anyway, it'll make work more efficient
Le Mercredi 14 Janvier 2004 18:44, Stefano Mazzocchi a écrit :
> On 12 Jan 2004, at 23:40, Sylvain Wallez wrote:
> > Stefano Mazzocchi wrote:
> >> On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
> >>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
> >>>>> "println()" style debugging seems to work quite well. A
> >>>>> source-level debugger is mainly required when the development
> >>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
> >>>>> Rhino has a JavaScript debugger, I rarely use it because println()
> >>>>> debugging is usually more efficient.
> >>>>
> >>>> I do the same for flowscript. But how can we insert a println() in
> >>>> a sitemap?
> >>>
> >>> How about adding a "message" attribute to ProcessingNode, e.g:
> >>>
> >>> <map:match pattern="page/*">
> >>> <map:generate type="jx" src="screens/{1}.xml" message="match
> >>> is page/{1}"/>
> >>> which would output something like
> >>>
> >>> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
> >>> page/getNumberA.html
> >>
> >> I like this very much!
> >>
> >> +1
> >
> > I don't like this and find it hacky. Using println in the flowscript
> > is a useful technique and as I said I use it. But introducing official
> > println equivalents all over the place will lead to floods of messages
> > scrolling on the console or filling the logs. Wouldn't a unified
> > debugger for the various languages cooperating in Cocoon (sitemap,
> > jxtemplate, woody form definitions, etc) be more useful?
>
> Debuggers are for wimps :-Prrr
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Jan 2004, at 11:46, Torsten Curdt wrote:
>> It seems to me like this thread mixes concerns between error
>> reporting (strack traces) and debugging or "processing monitoring"
>> (knowing what's going on at a high level).
>
> :) exactly
What I want is a way to know what my cocoon is doing at a level that I
understand the basic programmatic steps. Just like log() in flow or
log() in my java code, I want log() in my sitemap. What's wrong with
that?
And if you like a debugger and want to write it, fine, I just never
used it and never found the need for it.... but don't tell me "log in
sitemap is hacky, we should come up with a debugger" because that's not
how I want to work.
>> So it might be a good idea to have <map:log> write to a specific
>> logging category ("cocoon.processing"), where calls to
>> addCocoonStackTrace would be logged as well. The "cocoon.processing"
>> log category would then give a very useful high-level view of what's
>> going on.
>
> true ...it might be a bit hard to read when you have more than one user
> hitting that machine though ;)
don't know about you, but when I develop I'm the only one hitting the
cocoon instance I work on, so this is a nonissue, IMO.
--
Stefano.
Re: Cocoon Stack Traces
Posted by Torsten Curdt <tc...@vafer.org>.
> It seems to me like this thread mixes concerns between error reporting
> (strack traces) and debugging or "processing monitoring" (knowing what's
> going on at a high level).
:) exactly
> So it might be a good idea to have <map:log> write to a specific logging
> category ("cocoon.processing"), where calls to addCocoonStackTrace would
> be logged as well. The "cocoon.processing" log category would then give
> a very useful high-level view of what's going on.
true ...it might be a bit hard to read when you have more than one user
hitting that machine though ;)
--
Torsten
Re: Cocoon Stack Traces
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 13 jan 2004, à 03:41 Europe/Zurich, Tony Collen a écrit :
> Vadim Gritsenko wrote:
>
> [snip]
>
>> I don't like that message has been added to the core sitemap tags.
>> How about adding separate tag (ant-like):
>> <map:debug message=".... {1} ....."/>
>> It's easier to add/remove (comment/uncomment) a tag than an attribute.
>
> Or, arguing syntax even more: ;)
>
> <map:log level="debug|info|warn|foo">this is a message, substitution:
> {1}</map:log>
>
> or even
>
> <map:log level="foo" message="bar: {1}"/>
+1
It seems to me like this thread mixes concerns between error reporting
(strack traces) and debugging or "processing monitoring" (knowing
what's going on at a high level).
So it might be a good idea to have <map:log> write to a specific
logging category ("cocoon.processing"), where calls to
addCocoonStackTrace would be logged as well. The "cocoon.processing"
log category would then give a very useful high-level view of what's
going on.
-Bertrand
Re: Cocoon Stack Traces
Posted by Tony Collen <co...@umn.edu>.
Vadim Gritsenko wrote:
[snip]
>
> I don't like that message has been added to the core sitemap tags. How
> about adding separate tag (ant-like):
>
> <map:debug message=".... {1} ....."/>
>
> It's easier to add/remove (comment/uncomment) a tag than an attribute.
Or, arguing syntax even more: ;)
<map:log level="debug|info|warn|foo">this is a message, substitution:
{1}</map:log>
or even
<map:log level="foo" message="bar: {1}"/>
>
>
> Vadim
>
>
Tony
Re: Cocoon Stack Traces
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
>>
>>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>>>> "println()" style debugging seems to work quite well. A
>>>>> source-level debugger is mainly required when the development
>>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
>>>>> Rhino has a JavaScript debugger, I rarely use it because println()
>>>>> debugging is usually more efficient.
>>>>
>>>>
>>>>
>>>> I do the same for flowscript. But how can we insert a println() in
>>>> a sitemap?
>>>
>>>
>>>
>>> How about adding a "message" attribute to ProcessingNode, e.g:
>>>
>>> <map:match pattern="page/*">
>>> <map:generate type="jx" src="screens/{1}.xml" message="match
>>> is page/{1}"/>
>>> which would output something like
>>>
>>> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
>>> page/getNumberA.html
>>
I don't like that message has been added to the core sitemap tags. How
about adding separate tag (ant-like):
<map:debug message=".... {1} ....."/>
It's easier to add/remove (comment/uncomment) a tag than an attribute.
Vadim
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Jan 2004, at 23:40, Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
>>
>>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>>>> "println()" style debugging seems to work quite well. A
>>>>> source-level debugger is mainly required when the development
>>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
>>>>> Rhino has a JavaScript debugger, I rarely use it because println()
>>>>> debugging is usually more efficient.
>>>>
>>>>
>>>> I do the same for flowscript. But how can we insert a println() in
>>>> a sitemap?
>>>
>>>
>>> How about adding a "message" attribute to ProcessingNode, e.g:
>>>
>>> <map:match pattern="page/*">
>>> <map:generate type="jx" src="screens/{1}.xml" message="match
>>> is page/{1}"/>
>>> which would output something like
>>>
>>> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
>>> page/getNumberA.html
>>
>>
>> I like this very much!
>>
>> +1
>
>
> I don't like this and find it hacky. Using println in the flowscript
> is a useful technique and as I said I use it. But introducing official
> println equivalents all over the place will lead to floods of messages
> scrolling on the console or filling the logs. Wouldn't a unified
> debugger for the various languages cooperating in Cocoon (sitemap,
> jxtemplate, woody form definitions, etc) be more useful?
Debuggers are for wimps :-Prrr
--
Stefano.
Re: Cocoon Stack Traces
Posted by Joerg Heinicke <jo...@gmx.de>.
On 12.01.2004 23:40, Sylvain Wallez wrote:
>>> How about adding a "message" attribute to ProcessingNode, e.g:
>>>
>>> <map:match pattern="page/*">
>>> <map:generate type="jx" src="screens/{1}.xml" message="match
>>> is page/{1}"/>
>>> which would output something like
>>>
>>> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
>>> page/getNumberA.html
>>
>>
>>
>> I like this very much!
>>
>> +1
>
> I don't like this and find it hacky. Using println in the flowscript is
> a useful technique and as I said I use it. But introducing official
> println equivalents all over the place will lead to floods of messages
> scrolling on the console or filling the logs. Wouldn't a unified
> debugger for the various languages cooperating in Cocoon (sitemap,
> jxtemplate, woody form definitions, etc) be more useful?
>
> -0.9
>
> Sylvain
While I like the concept for the exception handling (as this was already
one of the biggest issues with Cocoon or hurdle to get Cocoon loved) I
also don't like the println above. How does SunBow ("Cocoon Debugger:
Stepping through the sitemap. Trace the XML stream and sitemap
variables.") handle these things? Isn't it extensible?
Joerg
Re: Cocoon Stack Traces
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 14.01.2004 21:28, Torsten Curdt wrote:
>
>>> I'm still +1 to <map:log> and see no real reason why not to do it.
>>
>>
>> All I am asking is ...do we really need it?
>
>
> IMO no. We should review the logging of the sitemap components and
> change it in that way that you get a clear meaning of the sitemap flow
> by setting log level to INFO.
No, this is debug information: it is needed only when something does not
work. INFO should be used for informational messages, like "abc request
processed in xyz milliseconds".
But to revise DEBUG messages (and reduce some to TRACE level) - this
should be good.
Vadim
Re: Cocoon Stack Traces
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.01.2004 21:28, Torsten Curdt wrote:
> [ Besides I still think *println* is bad in flowscript although it
> might be (well.. *is*) super for development. But having e.g. an
> optional flowscript console would be much better IMO. Otherwise:
> if we start using println... which components may use System.out
> which may not? ...this weakens a clean approach IMO: none should
> use println ]
What do we have flow.log for if not for logging? And why are all
exceptions in the flow logged to console - I don't like that!
>> I'm still +1 to <map:log> and see no real reason why not to do it.
>
> All I am asking is ...do we really need it?
IMO no. We should review the logging of the sitemap components and
change it in that way that you get a clear meaning of the sitemap flow
by setting log level to INFO.
Joerg
Re: Cocoon Stack Traces
Posted by Steven Noels <st...@outerthought.org>.
On Jan 15, 2004, at 2:44 AM, Stefano Mazzocchi wrote:
> Ok, let's add the cocoon stack trace only (no map:log or similar) for
> now and see what happens? deal?
+1
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 15 Jan 2004, at 03:37, Geoff Howard wrote:
> Christopher Oliver wrote:
>> I think <map:log> is still needed if you want to see the values of
>> sitemap variables while debugging.
hmmm, don't you get this already with the stacktraces? I mean, the
sitemap variables are normally used as:
1) tokens for URLs
2) tokens for parameters
the browser is the most intuitive console we have, and the URL is right
there up top... or, if something happens, is right in the cocoon
stacktrace.
My deal is: let's see how far we can go without it... at that point,
both sides will know if it's FS or if it's really needed.
> That sounds like a good point to me, and Stefano's "deal" sounds good
> to me.
Well, there is a conflict here since Chris wants it and my deal was
"let's wait until we can understand that it's really required".
> Maybe I'm missing the nuances of the discussion because I've been
> having to just skim lately, but it seems we're letting a good new
> feature slip away (the original stack traces) while an orthogonal
> discussion takes place (logging).
nonono, careful: Chris' stacktraces are great (Sylvain proposed
something like this a while ago but it didn't get implemented) and
nobody is against this.
We are just polishing a few rough edges, but the general idea is still
very valuable and there is strong consensus that it's a great feature.
--
Stefano.
Re: Cocoon Stack Traces
Posted by Geoff Howard <co...@leverageweb.com>.
Christopher Oliver wrote:
> Stefano Mazzocchi wrote:
>
>> On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
>
> <snip>
>
>>>> I'm still +1 to <map:log> and see no real reason why not to do it.
>>>
>>> All I am asking is ...do we really need it?
>>
>> hmmmm,
>>
>>>> [feeling hacky is not a real reason if there is no alternative
>>>> proposed and the need is felt...
>>>
>>> I am just wondering ...when do you need it? Usually I'd need it if
>>> something goes wrong. How often is something wrong in your sitemaps
>>> and you don't get an exception?
>>
>> This is a good point.
>>
>>> ...I am totally +1000 adding that wonderful cocoon stack trace
>>> to our exception handling.
>>>
>>> Just some RT ...what about a development mode (here comes the
>>> running mode again;) where you get a sitemap console and flowscript
>>> console. In the sitemap console you could see the stack trace of
>>> the last request ... in the flowscript console the log from
>>> the flowscript.
>>
>> Ok, let's add the cocoon stack trace only (no map:log or similar) for
>> now and see what happens? deal?
>>
>> --
>> Stefano.
>>
> I think <map:log> is still needed if you want to see the values of
> sitemap variables while debugging.
That sounds like a good point to me, and Stefano's "deal" sounds good to
me.
Maybe I'm missing the nuances of the discussion because I've been having
to just skim lately, but it seems we're letting a good new feature slip
away (the original stack traces) while an orthogonal discussion takes
place (logging).
Geoff
Re: Cocoon Stack Traces
Posted by Torsten Curdt <tc...@vafer.org>.
> I think <map:log> is still needed if you want to see the values of
> sitemap variables while debugging.
Would it be possible to modify the output from
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
sitemap: (mount at
file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
to something like this
sitemap: file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68
<map:mount pattern="whatever">
sitemap: file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65
<map:mount pattern="whatever">
sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
with the sitemap variables applied?
--
Torsten
Re: Cocoon Stack Traces
Posted by Christopher Oliver <re...@verizon.net>.
Stefano Mazzocchi wrote:
>
> On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
<snip>
>
>>> I'm still +1 to <map:log> and see no real reason why not to do it.
>>
>>
>> All I am asking is ...do we really need it?
>
>
> hmmmm,
>
>>> [feeling hacky is not a real reason if there is no alternative
>>> proposed and the need is felt...
>>
>>
>> I am just wondering ...when do you need it? Usually I'd need it if
>> something goes wrong. How often is something wrong in your sitemaps
>> and you don't get an exception?
>
>
> This is a good point.
>
>> ...I am totally +1000 adding that wonderful cocoon stack trace
>> to our exception handling.
>>
>> Just some RT ...what about a development mode (here comes the
>> running mode again;) where you get a sitemap console and flowscript
>> console. In the sitemap console you could see the stack trace of
>> the last request ... in the flowscript console the log from
>> the flowscript.
>
>
> Ok, let's add the cocoon stack trace only (no map:log or similar) for
> now and see what happens? deal?
>
> --
> Stefano.
>
>
I think <map:log> is still needed if you want to see the values of
sitemap variables while debugging.
Chris
Re: Cocoon Stack Traces
Posted by Torsten Curdt <tc...@vafer.org>.
> Ok, let's add the cocoon stack trace only (no map:log or similar) for
> now and see what happens? deal?
+1 deal :)
--
Torsten
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 14 Jan 2004, at 21:28, Torsten Curdt wrote:
>>>> I don't like this and find it hacky. Using println in the
>>>> flowscript is a useful technique and as I said I use it. But
>>>> introducing official println equivalents all over the place will
>>>> lead to floods of messages
>>>
>>>
>>> I'd like to second that.
>>>
>>> Besides I think we are mixing debugging with error reporting.
>>>
>>> For error reporting we don't necessarily need a println.
>>> As long as the exception carries all needed information we
>>> can display something useful inside the browser and/or the log.
>>>
>>> This came up once at a Cocoon Stammtisch in Frankfurt when we
>>> were talking about XSP debugging and error reporting: we could
>>> introduce an exception that swallows SAX events so we can store
>>> semantically useful information inside the exception. The events
>>> could then be put back into the error pipeline. A stylesheet could
>>> to the rest.
>>>
>>> ...or we have a couple of specific exceptions that have a toSAX()
>>> method...
>>>
>>> Anyway ...I'd prefer not to clutter the sitemap with println
>>> statements.
>> Replace "sitemap" with "my sitemaps": some people might like that...
>> but they are not forcing you to have them.
>
> Come on ...this is not an argument. We quite often abandoned some ideas
> that what were useful (to a certain degree) because we assumed FS or
> because we had some other concerns ...although noone was forced to
> use them!
Point well taken.
>> What you say above is like saying "I don't like cocoon.log() because
>> I would rather not clutter the flowscripts with println statements".
>
> Well, you got a point. Maybe it's my perception of the sitemap that
> makes me feel differently about the use of logging facilities inside
> flowscripts. I see the sitemap more as a configuration while
> flowscript is a programming language from my POV.
eheh, my perception is very different from this. Both sitemap and
flowscript are programming languages. The first is mostly declarative
and the second is mostly procedural. They apply well to some problems
and bad to others.
> [ Besides I still think *println* is bad in flowscript although it
> might be (well.. *is*) super for development. But having e.g. an
> optional flowscript console would be much better IMO. Otherwise:
> if we start using println... which components may use System.out
> which may not? ...this weakens a clean approach IMO: none should
> use println ]
I said "println" quoting you, but cocoon.log() does log to the cocoon
logs.
>> Just like there are views that I use during developers but don't use
>> in production, I could totally write a simple XSLT stylesheet that
>> strips off the <map:log> tags from the development sitemaps or turns
>> them into comments.
>
> You are not proposing to introduce sitemap pre-processing, are you?
no, of course not.
> You mean doing it by hand?
potentially [but yeah, I got carried away ;-)]
>> I'm still +1 to <map:log> and see no real reason why not to do it.
>
> All I am asking is ...do we really need it?
hmmmm,
>> [feeling hacky is not a real reason if there is no alternative
>> proposed and the need is felt...
>
> I am just wondering ...when do you need it? Usually I'd need it if
> something goes wrong. How often is something wrong in your sitemaps
> and you don't get an exception?
This is a good point.
> ...I am totally +1000 adding that wonderful cocoon stack trace
> to our exception handling.
>
> Just some RT ...what about a development mode (here comes the
> running mode again;) where you get a sitemap console and flowscript
> console. In the sitemap console you could see the stack trace of
> the last request ... in the flowscript console the log from
> the flowscript.
Ok, let's add the cocoon stack trace only (no map:log or similar) for
now and see what happens? deal?
--
Stefano.
Re: Cocoon Stack Traces
Posted by Torsten Curdt <tc...@vafer.org>.
>>> I don't like this and find it hacky. Using println in the flowscript
>>> is a useful technique and as I said I use it. But introducing
>>> official println equivalents all over the place will lead to floods
>>> of messages
>>
>>
>> I'd like to second that.
>>
>> Besides I think we are mixing debugging with error reporting.
>>
>> For error reporting we don't necessarily need a println.
>> As long as the exception carries all needed information we
>> can display something useful inside the browser and/or the log.
>>
>> This came up once at a Cocoon Stammtisch in Frankfurt when we
>> were talking about XSP debugging and error reporting: we could
>> introduce an exception that swallows SAX events so we can store
>> semantically useful information inside the exception. The events
>> could then be put back into the error pipeline. A stylesheet could
>> to the rest.
>>
>> ...or we have a couple of specific exceptions that have a toSAX()
>> method...
>>
>> Anyway ...I'd prefer not to clutter the sitemap with println
>> statements.
>
>
> Replace "sitemap" with "my sitemaps": some people might like that... but
> they are not forcing you to have them.
Come on ...this is not an argument. We quite often abandoned some ideas
that what were useful (to a certain degree) because we assumed FS or
because we had some other concerns ...although noone was forced to
use them!
> What you say above is like saying "I don't like cocoon.log() because I
> would rather not clutter the flowscripts with println statements".
Well, you got a point. Maybe it's my perception of the sitemap that
makes me feel differently about the use of logging facilities inside
flowscripts. I see the sitemap more as a configuration while
flowscript is a programming language from my POV.
[ Besides I still think *println* is bad in flowscript although it
might be (well.. *is*) super for development. But having e.g. an
optional flowscript console would be much better IMO. Otherwise:
if we start using println... which components may use System.out
which may not? ...this weakens a clean approach IMO: none should
use println ]
> Just like there are views that I use during developers but don't use in
> production, I could totally write a simple XSLT stylesheet that strips
> off the <map:log> tags from the development sitemaps or turns them into
> comments.
You are not proposing to introduce sitemap pre-processing, are you?
You mean doing it by hand?
> I'm still +1 to <map:log> and see no real reason why not to do it.
All I am asking is ...do we really need it?
> [feeling hacky is not a real reason if there is no alternative proposed
> and the need is felt...
I am just wondering ...when do you need it? Usually I'd need it if
something goes wrong. How often is something wrong in your sitemaps
and you don't get an exception?
...I am totally +1000 adding that wonderful cocoon stack trace
to our exception handling.
Just some RT ...what about a development mode (here comes the
running mode again;) where you get a sitemap console and flowscript
console. In the sitemap console you could see the stack trace of
the last request ... in the flowscript console the log from
the flowscript.
> and don't tell me that <map:act type="log"> is
> less hacky]
Be sure I won't :)
cheers
--
Torsten
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Jan 2004, at 11:39, Torsten Curdt wrote:
>>>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>>>>> "println()" style debugging seems to work quite well. A
>>>>>> source-level debugger is mainly required when the development
>>>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
>>>>>> Rhino has a JavaScript debugger, I rarely use it because
>>>>>> println() debugging is usually more efficient.
>>>>> I do the same for flowscript. But how can we insert a println() in
>>>>> a sitemap?
>>>> How about adding a "message" attribute to ProcessingNode, e.g:
>>> I like this very much!
>> I don't like this and find it hacky. Using println in the flowscript
>> is a useful technique and as I said I use it. But introducing
>> official println equivalents all over the place will lead to floods
>> of messages
>
> I'd like to second that.
>
> Besides I think we are mixing debugging with error reporting.
>
> For error reporting we don't necessarily need a println.
> As long as the exception carries all needed information we
> can display something useful inside the browser and/or the log.
>
> This came up once at a Cocoon Stammtisch in Frankfurt when we
> were talking about XSP debugging and error reporting: we could
> introduce an exception that swallows SAX events so we can store
> semantically useful information inside the exception. The events
> could then be put back into the error pipeline. A stylesheet could
> to the rest.
>
> ...or we have a couple of specific exceptions that have a toSAX()
> method...
>
> Anyway ...I'd prefer not to clutter the sitemap with println
> statements.
Replace "sitemap" with "my sitemaps": some people might like that...
but they are not forcing you to have them.
What you say above is like saying "I don't like cocoon.log() because I
would rather not clutter the flowscripts with println statements".
Just like there are views that I use during developers but don't use in
production, I could totally write a simple XSLT stylesheet that strips
off the <map:log> tags from the development sitemaps or turns them into
comments.
I'm still +1 to <map:log> and see no real reason why not to do it.
[feeling hacky is not a real reason if there is no alternative proposed
and the need is felt... and don't tell me that <map:act type="log"> is
less hacky]
--
Stefano.
Re: Cocoon Stack Traces
Posted by Torsten Curdt <tc...@vafer.org>.
>>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>>>> "println()" style debugging seems to work quite well. A
>>>>> source-level debugger is mainly required when the development
>>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
>>>>> Rhino has a JavaScript debugger, I rarely use it because println()
>>>>> debugging is usually more efficient.
>>>> I do the same for flowscript. But how can we insert a println() in a
>>>> sitemap?
>>> How about adding a "message" attribute to ProcessingNode, e.g:
>> I like this very much!
> I don't like this and find it hacky. Using println in the flowscript is
> a useful technique and as I said I use it. But introducing official
> println equivalents all over the place will lead to floods of messages
I'd like to second that.
Besides I think we are mixing debugging with error reporting.
For error reporting we don't necessarily need a println.
As long as the exception carries all needed information we
can display something useful inside the browser and/or the log.
This came up once at a Cocoon Stammtisch in Frankfurt when we
were talking about XSP debugging and error reporting: we could
introduce an exception that swallows SAX events so we can store
semantically useful information inside the exception. The events
could then be put back into the error pipeline. A stylesheet could
to the rest.
...or we have a couple of specific exceptions that have a toSAX()
method...
Anyway ...I'd prefer not to clutter the sitemap with println
statements.
cheers
--
Torsten
Re: Cocoon Stack Traces
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jorg Heymans wrote:
> <snipped a great deal>
>
>> I'm dead serious when I think that debuggers brain-damange their
>> users: debugging a program with a debugger instead of with a ton of
>> println is *much* slower for me. not only because of the many layers
>> of tool that have to run around my program, but also because logging
>> forces you to think about a strategy, think about where the problems
>> could be.. you
>
> How is setting a breakpoint different from inserting a logging
> statement? Breakpoint locations need to be carefully chosen as well with
> strategy. Ofcourse if you get it wrong you don't loose much time, just
> reset and rerun, no recompiling needed.
>
> If it wasn't for a debugger i would've spent so much more time getting
> to know the insides of cocoon. All i had to do was set a breakpoint
> somewhere in custom code and work my way up the calltrace to get a first
> feeling of how the cocoon internals are working.
You are both right.
Debuggers do brain-damange some users, and logging statements in some
cases are the only way to see things happening in real-life with
multiple threads (serverside *is* different).
On the other side debuggers can sometimes really speed things up,
especially in the code-knowledge area, and some can collect data exactly
like logging does, without manually stepping through each call.
Bottom line: the debugger and logging statements are nice hammers, but
not all nails are created equal ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Cocoon Stack Traces
Posted by peter royal <pr...@apache.org>.
On Jan 14, 2004, at 1:10 PM, Jorg Heymans wrote:
> How is setting a breakpoint different from inserting a logging
> statement? Breakpoint locations need to be carefully chosen as well
> with strategy. Ofcourse if you get it wrong you don't loose much
> time, just reset and rerun, no recompiling needed.
A debugger is just a tool. Its all about how you use it :)
Some people definitely apply the hammer anti-pattern to them, which I
think is what Stefano was speaking against.
-pete
Re: Cocoon Stack Traces
Posted by Jorg Heymans <jh...@domek.be>.
<snipped a great deal>
>
> I'm dead serious when I think that debuggers brain-damange their users:
> debugging a program with a debugger instead of with a ton of println is
> *much* slower for me. not only because of the many layers of tool that
> have to run around my program, but also because logging forces you to
> think about a strategy, think about where the problems could be.. you
How is setting a breakpoint different from inserting a logging
statement? Breakpoint locations need to be carefully chosen as well with
strategy. Ofcourse if you get it wrong you don't loose much time, just
reset and rerun, no recompiling needed.
If it wasn't for a debugger i would've spent so much more time getting
to know the insides of cocoon. All i had to do was set a breakpoint
somewhere in custom code and work my way up the calltrace to get a first
feeling of how the cocoon internals are working.
regards
Jorg
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 13 Jan 2004, at 09:47, Steven Noels wrote:
> On Jan 13, 2004, at 7:56 AM, Sylvain Wallez wrote:
>
>> However, do we really need a new sitemap statement? What about a
>> simple log action: <map:act type="log" src="blah blah"/>?
>
> +1
>
> IMHO, I find adding a println() type construct to the sitemap a bit of
> a hack (but admittedly less work than coming up with a full-blown
> debugging API + tools - although this approach might be better suited
> for all the different styles of development possible in Cocoon). I
> know the Apples concept is essentially doomed, but I saw Marc once
> hooking the Eclipse debugger into an Apple, and that seriously kicked
> ass - you don't need println() anymore of you have a full-blown
> debugger at your service.
Seriously, this time, but I *do* think that if you ever feel the need
for a debugger, you have a problem.
The Java Debug Interface is supposed to allow you to "inject" rewritten
code into the system. That might work for simple stuff, but I don't buy
that it could be able to work on top of, say, three different
classloaders (Loader + cocoon block manager + flowscript compiling
classloader).
I think that any form of serious logging is kickass as a debugging
tool. Debuggers to give you the perception that things can be traced
linearely, but this is rarely the case on the server side. Concurrency
and debuggers simply don't match.
And if you want to find out why your pipeline isn't called, logging the
message is more than enough to find out.
I'm dead serious when I think that debuggers brain-damange their users:
debugging a program with a debugger instead of with a ton of println is
*much* slower for me. not only because of the many layers of tool that
have to run around my program, but also because logging forces you to
think about a strategy, think about where the problems could be.. you
are *actively* debugging... debuggers turn your thinking into passive
mode, you don't have a strategy, you don't think in advance.
Having the ability to log directly from the sitemap is a great idea,
just like print() or cocoon.log() in flow is *super useful*
[and I agree with Vadim that <map:log> is much better than an attribute]
As for <map:act type="log">, it would achieve the same effect, yes, but
I think this is worth putting in the semantics of the sitemap as to
indicate to our users that this is the way we suggest them to look into
their sitemaps dynamics... an action might not give the same vision.
--
Stefano.
Re: Cocoon Stack Traces
Posted by Steven Noels <st...@outerthought.org>.
On Jan 13, 2004, at 10:34 AM, Bertrand Delacretaz wrote:
> Le Mardi, 13 jan 2004, à 09:47 Europe/Zurich, Steven Noels a écrit :
>> ... saw Marc once hooking the Eclipse debugger into an Apple, and
>> that seriously kicked ass - you don't need println() anymore of you
>> have a full-blown debugger at your service.
>
> Yes, if you're debugging java code it's fairly easy to setup the JVM
> for remote debugging before starting Cocoon, and then do whatever.
>
> But I don't think this helps for debugging flowscript or other stuff
> that Cocoon interprets by itself (sitemaps, XSLT, etc.). That's where
> a debugging framework could help.
Sure! I was basically trying to indicate my support for the effort of
going along that road instead of JFID with println() - but as Chris
pointed out, going for one doesn't exclude the other.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cocoon Stack Traces
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 13 jan 2004, à 09:47 Europe/Zurich, Steven Noels a écrit :
> ... saw Marc once hooking the Eclipse debugger into an Apple, and that
> seriously kicked ass - you don't need println() anymore of you have a
> full-blown debugger at your service.
Yes, if you're debugging java code it's fairly easy to setup the JVM
for remote debugging before starting Cocoon, and then do whatever.
But I don't think this helps for debugging flowscript or other stuff
that Cocoon interprets by itself (sitemaps, XSLT, etc.). That's where a
debugging framework could help.
-Bertrand
Re: Cocoon Stack Traces
Posted by Steven Noels <st...@outerthought.org>.
On Jan 13, 2004, at 7:56 AM, Sylvain Wallez wrote:
> However, do we really need a new sitemap statement? What about a
> simple log action: <map:act type="log" src="blah blah"/>?
+1
IMHO, I find adding a println() type construct to the sitemap a bit of
a hack (but admittedly less work than coming up with a full-blown
debugging API + tools - although this approach might be better suited
for all the different styles of development possible in Cocoon). I know
the Apples concept is essentially doomed, but I saw Marc once hooking
the Eclipse debugger into an Apple, and that seriously kicked ass - you
don't need println() anymore of you have a full-blown debugger at your
service.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Cocoon Stack Traces
Posted by Geoff Howard <co...@leverageweb.com>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> I don't think anyone is suggesting that there shouldn't be support for
>> a source level debugger. But that is a large project, IMO. And having
>> the ability to do "println" debugging doesn't preclude it.
>
> You're right.
>
> I agree with Vadim that an explicit sitemap instruction sounds better
> than an additional attribute on all existing instructions and like
> better Tony's second proposal: <map:log level="..." message="..."/>
>
> However, do we really need a new sitemap statement? What about a simple
> log action: <map:act type="log" src="blah blah"/>?
This would confuse people who place a log action after a generator in
the sitemap and assume it's executed before the generator wouldn't it?
Geoff
Re: Cocoon Stack Traces
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> I don't think anyone is suggesting that there shouldn't be support for
> a source level debugger. But that is a large project, IMO. And having
> the ability to do "println" debugging doesn't preclude it.
You're right.
I agree with Vadim that an explicit sitemap instruction sounds better
than an additional attribute on all existing instructions and like
better Tony's second proposal: <map:log level="..." message="..."/>
However, do we really need a new sitemap statement? What about a simple
log action: <map:act type="log" src="blah blah"/>?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Cocoon Stack Traces
Posted by Christopher Oliver <re...@verizon.net>.
I don't think anyone is suggesting that there shouldn't be support for a
source level debugger. But that is a large project, IMO. And having the
ability to do "println" debugging doesn't preclude it.
My $0.02,
Chris
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
>>
>>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>>>> "println()" style debugging seems to work quite well. A
>>>>> source-level debugger is mainly required when the development
>>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
>>>>> Rhino has a JavaScript debugger, I rarely use it because println()
>>>>> debugging is usually more efficient.
>>>>
>>>>
>>>>
>>>> I do the same for flowscript. But how can we insert a println() in
>>>> a sitemap?
>>>
>>>
>>>
>>> How about adding a "message" attribute to ProcessingNode, e.g:
>>>
>>> <map:match pattern="page/*">
>>> <map:generate type="jx" src="screens/{1}.xml" message="match
>>> is page/{1}"/>
>>> which would output something like
>>>
>>> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
>>> page/getNumberA.html
>>
>>
>>
>> I like this very much!
>>
>> +1
>
>
>
> I don't like this and find it hacky. Using println in the flowscript
> is a useful technique and as I said I use it. But introducing official
> println equivalents all over the place will lead to floods of messages
> scrolling on the console or filling the logs. Wouldn't a unified
> debugger for the various languages cooperating in Cocoon (sitemap,
> jxtemplate, woody form definitions, etc) be more useful?
>
> -0.9
>
> Sylvain
>
Re: Cocoon Stack Traces
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
>
>>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>>> "println()" style debugging seems to work quite well. A
>>>> source-level debugger is mainly required when the development
>>>> turnaround cycle is long (e.g. J2EE apps). For example, although
>>>> Rhino has a JavaScript debugger, I rarely use it because println()
>>>> debugging is usually more efficient.
>>>
>>>
>>> I do the same for flowscript. But how can we insert a println() in a
>>> sitemap?
>>
>>
>> How about adding a "message" attribute to ProcessingNode, e.g:
>>
>> <map:match pattern="page/*">
>> <map:generate type="jx" src="screens/{1}.xml" message="match
>> is page/{1}"/>
>> which would output something like
>>
>> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
>> page/getNumberA.html
>
>
> I like this very much!
>
> +1
I don't like this and find it hacky. Using println in the flowscript is
a useful technique and as I said I use it. But introducing official
println equivalents all over the place will lead to floods of messages
scrolling on the console or filling the logs. Wouldn't a unified
debugger for the various languages cooperating in Cocoon (sitemap,
jxtemplate, woody form definitions, etc) be more useful?
-0.9
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Cocoon Stack Traces
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
>>> Also with the fast edit - reload - test cycle provided by Cocoon,
>>> "println()" style debugging seems to work quite well. A source-level
>>> debugger is mainly required when the development turnaround cycle is
>>> long (e.g. J2EE apps). For example, although Rhino has a JavaScript
>>> debugger, I rarely use it because println() debugging is usually
>>> more efficient.
>>
>> I do the same for flowscript. But how can we insert a println() in a
>> sitemap?
>
> How about adding a "message" attribute to ProcessingNode, e.g:
>
> <map:match pattern="page/*">
> <map:generate type="jx" src="screens/{1}.xml" message="match is
> page/{1}"/>
> which would output something like
>
> sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
> page/getNumberA.html
I like this very much!
+1
--
Stefano.
Re: Cocoon Stack Traces
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Mmmh... if we push and pop stack frame indications, isn't it enough
>>> to build a debugger?
>>>
>>> The runtime part of the debugger can be a optional listener in
>>> add/popStackFrame which suspends the execution when a breakpoint is
>>> encountered (detected using the stack element's location).
>>>
>>> And we can also associate an additional object to a
>>> StackTraceElement that will give access to the variables in the
>>> element's scope. This will be e.g. an InvokeContext for the
>>> TreeProcessor or a [JXPath|Jexl]Context for JXTemplate. This allows
>>> the debugger do display and even modify the variables that drive the
>>> current request's execution.
>>
>>
>>
>> Without getting into all the details, I think a proper API for a
>> global debugger would require quite a bit more infrastructure than
>> what you're suggesting.
>
>
>
> Since AFAIK, you've written the Rhino debugger, can you enlighten us
> on the required infrastructure?
I'll try to write up something about this when I have a little time.
>
>
>> Also with the fast edit - reload - test cycle provided by Cocoon,
>> "println()" style debugging seems to work quite well. A source-level
>> debugger is mainly required when the development turnaround cycle is
>> long (e.g. J2EE apps). For example, although Rhino has a JavaScript
>> debugger, I rarely use it because println() debugging is usually more
>> efficient.
>
>
>
> I do the same for flowscript. But how can we insert a println() in a
> sitemap?
How about adding a "message" attribute to ProcessingNode, e.g:
<map:match pattern="page/*">
<map:generate type="jx" src="screens/{1}.xml" message="match is
page/{1}"/>
which would output something like
sitemap: C:/cocoon/build/webapp/samples/sitemap.xmap:16:20: match is
page/getNumberA.html
- Chris
Cocoon Debugger API (was Re: Cocoon Stack Traces)
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Mmmh... if we push and pop stack frame indications, isn't it enough
>>> to build a debugger?
>>
<snip>
>>>
>>
>> Without getting into all the details, I think a proper API for a
>> global debugger would require quite a bit more infrastructure than
>> what you're suggesting.
>
>
>
> Since AFAIK, you've written the Rhino debugger, can you enlighten us
> on the required infrastructure?
>
I've also written several other debuggers including a Java debugger and
a BPEL4WS debugger which are part of my company's IDE.
Besides knowledge of the call stack, a debugger requires support for
accessing variables and their properties (and sub-properties - for
display in a tree or tree-table), evaluating expressions, accessing the
source code, and notification of line changes (to manage breakpoints).
You also have to consider handling multiple threads and allowing for an
efficient wire-protocol for remote debugging.
Anyway, attached is a first try at an API.
1) First, a component that implements DebuggableComponent will be called
with setDebugger() if it is being debugged.
2) When that component begins execution and enters a "call", it calls
the enterFrame() method of the debugger passing in a DebuggableScope
object that it implements, and saves the return value (a DebugFrame).
3) During execution of that call, it notifies the debugger of line
changes by calling the onLineChange() method on the saved DebugFrame object.
4) If the call completes successully, it notifies the debugger by
calling the onExit() method on the DebugFrame.
5) If an exception occurs during the call, it notifies the debugger by
calling the onException() method on the DebugFrame
When a frame is entered, the debugger will save a reference to the
current DebuggableScope. Depending on its needs and on user input the
debugger will call methods on the saved DebuggableScope object to
evaluate expressions, get the values of variables, and to retrieve
source code.
Breakpoints are maintained internally by the debugger. When a breakpoint
is hit, it will block the component's call to onLineChange() until the
user steps or continues.
Note that all of the methods of DebuggableScope return String or
String[] in order to make remoting easy.
Also the mechanism provided to walk the object graph associated with a
variable is designed with JXPath in mind. For example, it can be
implemented easily lilke this:
public String[] getProperties(String var, String pointer) {
Object value = <get value of var>
JXPathContext varContext = JXPathContext.newContext(value);
Pointer ptr = varContext.getPointer(pointer);
JXPathContext ptrContext = varContext.getRelativeContext(ptr);
Iterator iter = ptrContext.iteratePointers("*");
List list = new LinkedList();
while (iter.hasNext()) {
Pointer p = (Pointer)iter.next();
list.add(p.asPath());
}
String[] ret = new String[list.size()];
list.toArray(ret);
return ret;
}
public String getValue(String var, String pointer) {
Object value = <get value of var>
JXPathContext varContext = JXPathContext.newContext(value);
return varContext.getValue(pointer);
}
What do you think?
--
Chris
Re: Cocoon Stack Traces
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> Mmmh... if we push and pop stack frame indications, isn't it enough
>> to build a debugger?
>>
>> The runtime part of the debugger can be a optional listener in
>> add/popStackFrame which suspends the execution when a breakpoint is
>> encountered (detected using the stack element's location).
>>
>> And we can also associate an additional object to a StackTraceElement
>> that will give access to the variables in the element's scope. This
>> will be e.g. an InvokeContext for the TreeProcessor or a
>> [JXPath|Jexl]Context for JXTemplate. This allows the debugger do
>> display and even modify the variables that drive the current
>> request's execution.
>
>
> Without getting into all the details, I think a proper API for a
> global debugger would require quite a bit more infrastructure than
> what you're suggesting.
Since AFAIK, you've written the Rhino debugger, can you enlighten us on
the required infrastructure?
> Also with the fast edit - reload - test cycle provided by Cocoon,
> "println()" style debugging seems to work quite well. A source-level
> debugger is mainly required when the development turnaround cycle is
> long (e.g. J2EE apps). For example, although Rhino has a JavaScript
> debugger, I rarely use it because println() debugging is usually more
> efficient.
I do the same for flowscript. But how can we insert a println() in a
sitemap?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Cocoon Stack Traces
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
>
> Mmmh... if we push and pop stack frame indications, isn't it enough to
> build a debugger?
>
> The runtime part of the debugger can be a optional listener in
> add/popStackFrame which suspends the execution when a breakpoint is
> encountered (detected using the stack element's location).
>
> And we can also associate an additional object to a StackTraceElement
> that will give access to the variables in the element's scope. This
> will be e.g. an InvokeContext for the TreeProcessor or a
> [JXPath|Jexl]Context for JXTemplate. This allows the debugger do
> display and even modify the variables that drive the current request's
> execution.
Without getting into all the details, I think a proper API for a global
debugger would require quite a bit more infrastructure than what you're
suggesting. Also with the fast edit - reload - test cycle provided by
Cocoon, "println()" style debugging seems to work quite well. A
source-level debugger is mainly required when the development turnaround
cycle is long (e.g. J2EE apps). For example, although Rhino has a
JavaScript debugger, I rarely use it because println() debugging is
usually more efficient.
Regards,
Chris
Re: Cocoon Stack Traces
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
>
> Sylvain Wallez wrote:
>
>> Christopher Oliver wrote:
>>
>>> I started looking into how I could get a meaningful stack trace
>>> (with location information) spanning (possibly nested) invocations
>>> of the sitemap, flowscript, and JXTemplateGenerator.
>>
>>
>> <snip>
>>
>>> WDYT?
>>
>>
>> /me thinks it's great!
>>
>> Some low-level remarks, however:
>>
>> - we need a "popStackFrame()" method, since once a component has been
>> executed successfully and execution continues in its following
>> siblings, it should no longer appear in the stack trace
>
>
> The idea is that this stack trace is created during exception processing:
>
> try {
> do whatever
> } catch (Exception e) {
> Cocoon.addCocoonStackTrace("failed to do whatever", "comp",
> "method", uri, line, column);
> throw e;
> }
>
> Thus, during normal processing there is no overhead. That's why
> there's no popStackFrame().
Ok, I see.
>> - is the "message" parameter really needed? It's only meaningful for
>> the statement where the error occured, and will be present in the
>> Java exception that is raised.
>
>
> I guess you're right, but my thinking was that additional information
> about the call site could be useful. If there's no additional
> information you can just pass null.
>
>> - consequently, to minimize performance overhead, I think it would be
>> better to pass a single StackTraceElement parameter (or
>> "CocoonStackFrame"?), since these objects can be pre-allocated at
>> script/template/sitemap load time and are immutable afterwards.
>
>
> See above.
>
>> - I don't like much putting this on the "Cocoon" class. What about
>> creating a "org.apache.cocoon.util.debug" package holding the various
>> classes that will certainly follow this first enhancement. I'm
>> thinking to a global debugger that may be built using these stack
>> frames.
>
>
> This approach was only designed to support exception reporting, not to
> support debug tracing or to develop a debugger. For those purposes a
> different design is required.
Mmmh... if we push and pop stack frame indications, isn't it enough to
build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
encountered (detected using the stack element's location).
And we can also associate an additional object to a StackTraceElement
that will give access to the variables in the element's scope. This will
be e.g. an InvokeContext for the TreeProcessor or a [JXPath|Jexl]Context
for JXTemplate. This allows the debugger do display and even modify the
variables that drive the current request's execution.
The cost is two method calls per stack frame (push and pop), which
implementation can be reduced to a single test against null when no
stacktrace nor debugging is wanted.
public class StackFrameRecorder {
public static void pushStackFrame(Map ObjectModel, CocoonStackFrame
frame, Object frameData)
public static void popStackFrame(Map ObjectModel)
}
The CocoonStackFrame, along with the location information you described,
will also have a method to wrap the frame-specific data into e.g. a
standard Map that will be used by the debugger to display and modify
"variables". That way, the debugger doesn't have to handle each
particular kind of frameData, but the conversion cost is only to be paid
when the debugger wants to display them.
public abstract class CocoonStackFrame {
public String getURI() // and other location properties
public abstract Map getVariables(Object frameData);
}
Need to think more about the details, but the small cost of the two
method calls per frame may really be worth it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Cocoon Stack Traces
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> I started looking into how I could get a meaningful stack trace (with
>> location information) spanning (possibly nested) invocations of the
>> sitemap, flowscript, and JXTemplateGenerator.
>
> <snip>
>
>>
>> WDYT?
>
>
>
> /me thinks it's great!
>
> Some low-level remarks, however:
>
> - we need a "popStackFrame()" method, since once a component has been
> executed successfully and execution continues in its following
> siblings, it should no longer appear in the stack trace
The idea is that this stack trace is created during exception processing:
try {
do whatever
} catch (Exception e) {
Cocoon.addCocoonStackTrace("failed to do whatever", "comp",
"method", uri, line, column);
throw e;
}
Thus, during normal processing there is no overhead. That's why there's
no popStackFrame().
>
> - is the "message" parameter really needed? It's only meaningful for
> the statement where the error occured, and will be present in the Java
> exception that is raised.
I guess you're right, but my thinking was that additional information
about the call site could be useful. If there's no additional
information you can just pass null.
>
>
> - consequently, to minimize performance overhead, I think it would be
> better to pass a single StackTraceElement parameter (or
> "CocoonStackFrame"?), since these objects can be pre-allocated at
> script/template/sitemap load time and are immutable afterwards.
See above.
>
>
> - I don't like much putting this on the "Cocoon" class. What about
> creating a "org.apache.cocoon.util.debug" package holding the various
> classes that will certainly follow this first enhancement. I'm
> thinking to a global debugger that may be built using these stack frames.
This approach was only designed to support exception reporting, not to
support debug tracing or to develop a debugger. For those purposes a
different design is required.
Regards,
Chris
Re: Cocoon Stack Traces
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> I started looking into how I could get a meaningful stack trace (with
> location information) spanning (possibly nested) invocations of the
> sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
> stack trace produces a poor result. Although location information is
> available it isn't provided according to a consistent model. Rhino
> stores a JS stack trace in a JavaScriptException. JXTemplateGenerator
> stores its execution stack trace in a sequence of nested
> SAXParseExceptions. The Sitemap processor currently doesn't seem to
> produce an execution stack trace, but ProcessingNode's have location
> information so it should be possible. In addition,
> javax.xml.transform.TransformerException has location information.
> o.a.c.ProcessingException gives special treatment to SAXParseException
> and TransformerException and adds location information to its own
> stack trace (but only for one level - it doesn't included nested
> SAXParseException's, for example). There seem to be various other
> hacks to attempt to include location information in the exception
> message or stack trace.
>
> The idea is to allow a Cocoon processing element that operates on
> source code (sitemap, flowscript, jxtemplate, etc...) to provide
> location information about the execution stack of that processing
> element when the exception occurred (see also
> http://marc.theaimsgroup.com/?t=105597249800001&r=1&w=2).
>
> To accomplish this I chose not to use the JVM exception stack trace
> but instead to store a "Cocoon" stack trace in the current object
> model. I added the following to the class o.a.c.Cocoon:
>
> public class Cocoon {
> ....
> public interface StackTraceElement {
> public String getComponent();
> public String getMessage();
> public String getMethod();
> public String getURI();
> public int getLineNumber();
> public int getColumnNumber();
> }
>
> public static void addCocoonStackTrace(
> Map objectModel,
> String message,
> String component,
> String method,
> String uri,
> int lineNumber,
> int columnNumber);
>
> public static ArrayList /* of StackTraceElement */
> getStackTrace(Map objectModel)
>
> }
>
> I added calls to addCocoonStackTrace() in JXTemplateGenerator,
> FOM_JavaScriptInterpreter, and in MountNode.java and CallNode.java.
>
> With a method like the following:
>
> private static void dumpStackTrace(Map objectModel) {
<snip/>
> I was able to produce the following output:
>
> jxtemplate: No pointer for xpath: $blah (at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/screens/getNumberA.xml,
> Line 26.13)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
> sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
> flowscript: (at
> resource://org/apache/cocoon/components/flow/javascript/fom/fom_system.js,
> Line 4)
> flowscript: (getNumber at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js,
> Line 31)
> flowscript: (calculator at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/../calc/calc.js,
> Line 11)
> sitemap: (call at
> file:/C:/cocoon4/build/webapp/samples/flow/jxcalc/sitemap.xmap:48:42)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/flow/sitemap.xmap:38:68)
> sitemap: (mount at
> file:/C:/cocoon4/build/webapp/samples/sitemap.xmap:154:65)
> sitemap: (mount at file:/C:/cocoon4/build/webapp/sitemap.xmap:738:66)
>
> It seems straightforward to hook this into Cocoon's error reporter.
>
> WDYT?
/me thinks it's great!
Some low-level remarks, however:
- we need a "popStackFrame()" method, since once a component has been
executed successfully and execution continues in its following siblings,
it should no longer appear in the stack trace
- is the "message" parameter really needed? It's only meaningful for the
statement where the error occured, and will be present in the Java
exception that is raised.
- consequently, to minimize performance overhead, I think it would be
better to pass a single StackTraceElement parameter (or
"CocoonStackFrame"?), since these objects can be pre-allocated at
script/template/sitemap load time and are immutable afterwards.
- I don't like much putting this on the "Cocoon" class. What about
creating a "org.apache.cocoon.util.debug" package holding the various
classes that will certainly follow this first enhancement. I'm thinking
to a global debugger that may be built using these stack frames.
> In the process of doing this, however, I found that pipeline
> processing doesn't actually occur during sendPage*(). Instead, it
> simply sets a flag to redirect to the passed uri and returns. Pipeline
> processing actually occurs after the flowscript has completed. This is
> also a problem for the solution proposed here to release components
> after pipeline processing:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107360524206262&w=2.
>
> To solve both problems I modified the implementation of sendPage*() to
> call the sitemap processor recursively instead. It seems to work. Does
> anyone know of a problem with this approach?
Or we can also have internal redirects be handled at the location where
they occur instead of raising this flag. The purpose of going through
this flag was to both ensure a single handling location (this can be
achieved by other means) and cut down the length of java stack traces.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com