cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cocoon Stack Traces
Date Mon, 12 Jan 2004 17:03:21 GMT
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 


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message