You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/04/01 04:49:37 UTC
[action2] Debugging interceptor for devMode
Sorry, forgot the [action2] tag...
Don Brown wrote:
> I've created an interceptor that I've found invaluable for debugging.
> When you append "debug=true" to the query string, this interceptor
> hijacks the normal result and instead, dumps the parameters, context,
> session, and value stack to the response as XML. Since most browsers
> know how to handle XML, this is a great tool for getting a view at the
> data behind the page. The interceptor only works when devMode is set to
> true.
>
> I'm putting this in as a ticket[1], because I'd like some feedback
> first. It is my intention to put this interceptor into the default
> stack. Since it only engages when devMode is enabled, it should be safe
> and have little effect on production applications.
>
> Don
>
> [1] http://issues.apache.org/struts/browse/WW-1279
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Debugging interceptor for devMode
Posted by Don Brown <mr...@twdata.org>.
I've since added additional capabilities and committed it. To enable
it, add the 'debug' parameter to your querystring. Different values
give different results:
- 'xml' gives you an XML dump of the request, parameters, session,
context, and value stack
- 'console' gives you an AJAX-enabled OGNL console that lets you test
OGNL expressions on the live data. The context is also dumped to XML
and the original page is shown.
To test it, run the following commands with Java 5 as your default jdk:
- ant
- java -jar build/struts-action-2.0-dev.jar quickstart:starter
Then in your browser:
- http://localhost:8080/starter/helloMatrix.action
- http://localhost:8080/starter/helloMatrix.action?debug=xml
- http://localhost:8080/starter/helloMatrix.action?debug=console
This uses the great QuickStart tool that packages an auto-compiling
application server into the struts-action jar.
Gabe wrote:
> Don,
>
> Sounds interesting but I wonder if it can be expanded to be made more flexible:
> 1) Create an XML result type (is there one already?) and a global result of that type that is the result that the interceptor forwards to if "debug=true". This XML result type could (eventually or now) then be used to print XML for a variety of uses (perhaps, such as creating DWR like javascript objects for AJAX calls or outputting SOAP responses).
>
I'm not sure how you'd have a certain result fire based on a request
parameter. The only way I found was to use an interceptor, and have it
register a PreResultInterceptor so that I could do things after the
Action had executed, but before the result ran. If my "things" closed
the output stream, then obviously the next result couldn't do anything.
There is probably a cleaner way to do that.
> 2) have an optional parameter to this interceptor that allows you to change the global result. Thus, you could write your own result that dealt with the debug differently than xml.
>
That is a good idea. So you are saying we'd still have an interceptor?
How can an interceptor change the result from an action? It seems the
PreResultInterceptor only gets a copy of the result string, not able to
modify it. I like the idea of making it more pluggable, though.
> 3) I wouldn't use the parameter name 'debug' because it is generic and might be used by applications for other things. We wouldn't want developers to have a debug=true parameter used for other reasons and then suddenly everything is printed out as XML (maybe printForDebug=true instead?)
>
Yeah, that is a good point. Perhaps the default is 'debug', but you can
change it by setting an interceptor parameter. FWIW, the version only
does things if debug equals 'xml', 'console', or 'command'.
> As an aside, another thing to consider is whether the interceptor should be part of Struts or XWork. Since the interceptor itself doesn't really have a web specific scope, I would say that it really belongs as a contribution to XWork. (Or at least this is the way the relationship btw XWork and Webwork used to work).
>
It seems like it would work fine for XWork, but it requires access to
the response's output stream. I guess we could abstract all the non
response-writing code and put that in XWork. I'd be fine with that.
Thanks for the great feedback and ideas!
Don
> Gabe
>
>
>
> ----- Original Message ----
> From: Don Brown <mr...@twdata.org>
> To: Struts Developers List <de...@struts.apache.org>
> Sent: Friday, March 31, 2006 9:49:37 PM
> Subject: [action2] Debugging interceptor for devMode
>
> Sorry, forgot the [action2] tag...
>
> Don Brown wrote:
>
>> I've created an interceptor that I've found invaluable for debugging.
>> When you append "debug=true" to the query string, this interceptor
>> hijacks the normal result and instead, dumps the parameters, context,
>> session, and value stack to the response as XML. Since most browsers
>> know how to handle XML, this is a great tool for getting a view at the
>> data behind the page. The interceptor only works when devMode is set to
>> true.
>>
>> I'm putting this in as a ticket[1], because I'd like some feedback
>> first. It is my intention to put this interceptor into the default
>> stack. Since it only engages when devMode is enabled, it should be safe
>> and have little effect on production applications.
>>
>> Don
>>
>> [1] http://issues.apache.org/struts/browse/WW-1279
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Debugging interceptor for devMode
Posted by Gabe <gj...@yahoo.com>.
Don,
Sounds interesting but I wonder if it can be expanded to be made more flexible:
1) Create an XML result type (is there one already?) and a global result of that type that is the result that the interceptor forwards to if "debug=true". This XML result type could (eventually or now) then be used to print XML for a variety of uses (perhaps, such as creating DWR like javascript objects for AJAX calls or outputting SOAP responses).
2) have an optional parameter to this interceptor that allows you to change the global result. Thus, you could write your own result that dealt with the debug differently than xml.
3) I wouldn't use the parameter name 'debug' because it is generic and might be used by applications for other things. We wouldn't want developers to have a debug=true parameter used for other reasons and then suddenly everything is printed out as XML (maybe printForDebug=true instead?)
As an aside, another thing to consider is whether the interceptor should be part of Struts or XWork. Since the interceptor itself doesn't really have a web specific scope, I would say that it really belongs as a contribution to XWork. (Or at least this is the way the relationship btw XWork and Webwork used to work).
Gabe
----- Original Message ----
From: Don Brown <mr...@twdata.org>
To: Struts Developers List <de...@struts.apache.org>
Sent: Friday, March 31, 2006 9:49:37 PM
Subject: [action2] Debugging interceptor for devMode
Sorry, forgot the [action2] tag...
Don Brown wrote:
> I've created an interceptor that I've found invaluable for debugging.
> When you append "debug=true" to the query string, this interceptor
> hijacks the normal result and instead, dumps the parameters, context,
> session, and value stack to the response as XML. Since most browsers
> know how to handle XML, this is a great tool for getting a view at the
> data behind the page. The interceptor only works when devMode is set to
> true.
>
> I'm putting this in as a ticket[1], because I'd like some feedback
> first. It is my intention to put this interceptor into the default
> stack. Since it only engages when devMode is enabled, it should be safe
> and have little effect on production applications.
>
> Don
>
> [1] http://issues.apache.org/struts/browse/WW-1279
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org