Re: Cocoon stack traces
Le 1 août 05, à 15:10, Sylvain Wallez a écrit : ...Tell me what you think! /me thinks that this is just great, thanks Sylvain! -Bertrand, thinking about launching polishyourheroplates.com smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon stack traces
Bertrand Delacretaz wrote: Le 1 août 05, à 15:10, Sylvain Wallez a écrit : ...Tell me what you think! /me thinks that this is just great, thanks Sylvain! Thanks! I just committed a few changes in the flow engine so that we have JS stacktraces in the Cocoon stacktrace! -Bertrand, thinking about launching polishyourheroplates.com LOL :-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Cocoon stack traces
Hi all, I have refactored the error handling stuff to have Cocoon stack traces, i.e. a trace of the involved components and the corresponding locations in the call stack. For example, we can track nested JXTG macro calls, flowscript function calls, pipeline locations, mounted sitemaps, etc. More locations will be added in the future. This refactoring is based on a few new features: Location management --- The new org.apache.cocoon.util.location package defines the Location class (a URI, line and column numbers) and a Locatable interface for objects that have a Location. The LocatorAsAttributesPipe is a SAX filter that registers parser location information as attributes on elements. This used by CForms to parse form definitions and bindings, thus removing the dependency on some Xerces internal APIs. The LocatedException and LocatedRuntimeException classes are exceptions that implement Locatable and therefore hold a Location. ProcessingException now extends LocatedException so that we're able to attach a location to a processing error. The class org.apache.cocoon.util.ExceptionUtils allows to get the location of LocatedException and some other well-known exception classes that hold a location (e.g. SAXParseException). Exception management A Cocoon stacktrace is defined by all exceptions in an exception chain that have a location. To add a particular statement to a Cocoon stacktrace, it is therefore necessary to provide this location information. This requires that we identify those places that we want to see in stacktraces, and make sure to catch exceptions and rethrow them wrapped in a LocatedException. I did this already for a few strategic places: flowscript calls, serialize statemements (that trigger execution of a pipeline) and mounts. The JTXG was already doing this wrapping using SAXParseException in macro calls. Exception display and log - The NotifyingGenerator and the associated stuff is... ahem... very complicated for something simple, and modifying it to handle a set of locations rather than a single one didn't seem obvious. I therefore wrote a new ExceptionGenerator that directly dumps as XML the Throwable catched by map:handle-errors, including all the needed location and stacktrace information. You can see it in action when an error occurs: a new Cocoon stacktrace section is now displayed along with the not-so-friendly Java stacktraces. And since these error pages should not be used in production, I also made sure that a LocatedException correctly prints the location in printStackTrace() so that we have the same information in the log files. Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stack traces
Sylvain Wallez wrote: big-snip/ Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! Wow. This is neat. For the curious, fire this up and go to: http://localhost:/samples/errorhandling/ Below is what I saw when I went there. Now isn't this better than extremely long java stack traces? Thanks Sylvain! Regards, Upayavira An error has occured org.xml.sax.SAXParseException: The markup in the document preceding the root element must be well-formed. context://samples/errorhandling/sitemap.xmap - 18:2 Cocoon stacktrace[hide] The markup in the document preceding the root element must be well-formed. context://samples/errorhandling/sitemap.xmap - 18:2 Sitemap: error when calling sub-sitemap context://samples/sitemap.xmap - 183:65 Sitemap: error when calling sub-sitemap context://sitemap.xmap - 852:66 Java stacktrace[show] Java full stacktrace[show] The Apache Cocoon Project
Re: Cocoon stack traces
Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto: I have refactored the error handling stuff to have Cocoon stack traces, i.e. a trace of the involved components and the corresponding locations in the call stack. I think it's time to take that hero plate out of the closet and polish it again ;-) Ugo attachment: hero.jpg -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Cocoon stack traces
Ugo Cei wrote: Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto: I have refactored the error handling stuff to have Cocoon stack traces, i.e. a trace of the involved components and the corresponding locations in the call stack. I think it's time to take that hero plate out of the closet and polish it again ;-) ROTFL !!! I'm currently working on the next Big Thing in error handling: getting real exceptions out of Xalan instead of a stupid RuntimeException. Maybe I should wait a bit to have my plate polished again later :-P Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Cocoon stack traces
Sylvain Wallez wrote: Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! big +1! -- Stefano.
Re: Pipleline Execution Stack Trace (was Cocoon Stack Traces)
Christopher Oliver wrote: So I would propose something like the following: 1) Have the TreeProcessor pass the sitemap source location in setGenerator(), addTransformer(), and setSerializer() to the ProcessingPipeline. 2) In Debug mode instrument the PipelineProcessor to write the output of each stage to a temporary file and regenerate SAX events from the temporary file (with location information). The PipelineProcessor would catch any exception thrown by a pipeline component and generate a Cocoon stack trace that includes the source location of the temp file. The Cocoon error reporter could even display the source code (maybe in tab-panes or whatever) of the pipeline intermediate results together with the stack trace. Hypothetically the label or tooltip on the tab-pane would be something like: C:\TEMP\Pipeline_1060734815693.xml (output of C:\cocoon\build\webapp\samples\sitemap.xmap::66:16) where the sitemap location refers to a map:generate or map:transform instruction. WDYT? IIRC, profiler pipeline already does some of this, like it saves output of every stage. Me thinks this debug mode should be part of profiling pipeline. PS I don't like writing to a temp file part Vadim
Re: Pipleline Execution Stack Trace (was Cocoon Stack Traces)
Vadim Gritsenko wrote: Christopher Oliver wrote: So I would propose something like the following: 1) Have the TreeProcessor pass the sitemap source location in setGenerator(), addTransformer(), and setSerializer() to the ProcessingPipeline. 2) In Debug mode instrument the PipelineProcessor to write the output of each stage to a temporary file and regenerate SAX events from the temporary file (with location information). The PipelineProcessor would catch any exception thrown by a pipeline component and generate a Cocoon stack trace that includes the source location of the temp file. The Cocoon error reporter could even display the source code (maybe in tab-panes or whatever) of the pipeline intermediate results together with the stack trace. Hypothetically the label or tooltip on the tab-pane would be something like: C:\TEMP\Pipeline_1060734815693.xml (output of C:\cocoon\build\webapp\samples\sitemap.xmap::66:16) where the sitemap location refers to a map:generate or map:transform instruction. WDYT? IIRC, profiler pipeline already does some of this, like it saves output of every stage. Me thinks this debug mode should be part of profiling pipeline. I am aware of that from: http://marc.theaimsgroup.com/?t=10677658321r=1w=2 But profiling seems like a separate concern. PS I don't like writing to a temp file part Vadim Why not (curious as to exact reason)? The idea is that this is analagous to running a C compiler (which is also a pipeline, BTW) with cc -i -s to save the preprocessor and assembler output. Chris
Re: Cocoon Stack Traces
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon Stack Traces
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
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
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.
Cocoon Debugger API (was Re: Cocoon Stack Traces)
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
// Hypothetical Debugging API:
// This interface is implemented by a processing component that can be debugged.
// It represents the current stack frame from the component's point of view
public interface DebuggableScope {
// Get the name of the component that implements this scope
public String getComponentName();
// Get the current method being executed
public String getMethod();
// Get a list of the names of the variables visible in this scope
public String[] getVariables() throws Exception;
// Get a list of pointers to the immediate properties of a variable
public String[] getProperties(String var) throws Exception;
// Get a list of pointers to the subproperties of a property
public String[] getProperties(String var, String pointer) throws Exception;
// Get the value of a variable
public String getValue(String var) throws Exception;
// Get the value of the sub[-sub,...] property of {var} identified by {pointer}
public String getValue(String var, String pointer) throws Exception;
// Evaluate {expression} in the current scope
public String evaluate(String expression) throws Exception;
// Return the source code identified by uri
public String resolveSource(String uri) throws Exception;
}
// This interface is implemented by the debugger itself. It represents the
// current stack frame from the debugger's point of view.
public interface DebugFrame {
// Get the caller
public DebugFrame getCaller();
// Get the scope associated with this frame
public DebuggableScope getScope();
// Notify the debugger of a line change
public void onLineChange(String uri, int line);
// Notify the debugger of the
Re: Cocoon Stack Traces
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
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
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
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
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
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
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Cocoon Stack Traces
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
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
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
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? h, [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
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? h, [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
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
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? h, [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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon Stack Traces
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
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
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon Stack Traces
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
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
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=10559724981r=1w=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
Re: Cocoon Stack Traces
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
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
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
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
Re: Cocoon Stack Traces
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=10559724981r=1w=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
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
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
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
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
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
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
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
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
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
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|foothis is a message, substitution:
{1}/map:log
or even
map:log level=foo message=bar: {1}/
Vadim
Tony
Re: Cocoon Stack Traces
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|foothis 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
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
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=10559724981r=1w=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.
