You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "John Lindal (JIRA)" <ji...@apache.org> on 2010/12/16 02:21:01 UTC
[jira] Created: (WW-3546) Add ability to control devMode per
request
Add ability to control devMode per request
------------------------------------------
Key: WW-3546
URL: https://issues.apache.org/jira/browse/WW-3546
Project: Struts 2
Issue Type: New Feature
Components: Core Interceptors, Dispatch Filter, Plugin - JSON
Affects Versions: 2.2.1
Reporter: John Lindal
Priority: Minor
I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
1) Is this the best solution?
2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WW-3546) Add ability to control devMode per
request
Posted by "John Lindal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Lindal reassigned WW-3546:
-------------------------------
Assignee: John Lindal
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Assignee: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-3546) Add ability to control devMode per
request
Posted by "Maurizio Cucchiara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971961#action_12971961 ]
Maurizio Cucchiara commented on WW-3546:
----------------------------------------
request parameters were my first security concern.
On the other hand implementing a robust signed cookie's generator could be more time-consuming task then the ability to enable dev mode per-request itself
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-3546) Add ability to control devMode per
request
Posted by "Maurizio Cucchiara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971960#action_12971960 ]
Maurizio Cucchiara commented on WW-3546:
----------------------------------------
request parameters were my first security concern.
On the other hand implementing a robust signed cookie's generator could be more time-consuming task then the ability to enable dev mode per-request itself
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-3546) Add ability to control devMode per
request
Posted by "Maurizio Cucchiara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971938#action_12971938 ]
Maurizio Cucchiara commented on WW-3546:
----------------------------------------
So, I guess you can enable debug mode by passing an extra parameter to the request, don't you?
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-3546) Add ability to control devMode per
request
Posted by "Lukasz Lenart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukasz Lenart updated WW-3546:
------------------------------
Fix Version/s: 2.2.2
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Assignee: John Lindal
> Priority: Minor
> Fix For: 2.2.2
>
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WW-3546) Add ability to control devMode per
request
Posted by "John Lindal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971958#action_12971958 ]
John Lindal commented on WW-3546:
---------------------------------
Yes, that's one way, but it's not secure. I use a signed cookie so external users cannot access the debugging features.
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-3546) Add ability to control devMode per
request
Posted by "John Lindal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Lindal resolved WW-3546.
-----------------------------
Resolution: Fixed
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Assignee: John Lindal
> Priority: Minor
> Fix For: 2.2.2
>
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WW-3546) Add ability to control devMode per
request
Posted by "John Lindal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972152#action_12972152 ]
John Lindal commented on WW-3546:
---------------------------------
I don't think Struts should implement the method for setting the flag. The signed cookie that I'm using is actually generated by a corp-wide login service. I just use a corp library to check that it's valid.
I was only suggesting that Struts could provide the flag, so if it is set, it modifies (some uses of) devMode for that request.
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-3546) Add ability to control devMode per
request
Posted by "John Lindal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980322#action_12980322 ]
John Lindal commented on WW-3546:
---------------------------------
I put the InheritableThreadLocal object in my copy of FilterDispatcher. That is the entry point to the Struts2 code in the request's thread. If anybody has a better suggestion for its location, please let me know!
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-3546) Add ability to control devMode per
request
Posted by "Maurizio Cucchiara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WW-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maurizio Cucchiara updated WW-3546:
-----------------------------------
Comment: was deleted
(was: request parameters were my first security concern.
On the other hand implementing a robust signed cookie's generator could be more time-consuming task then the ability to enable dev mode per-request itself)
> Add ability to control devMode per request
> ------------------------------------------
>
> Key: WW-3546
> URL: https://issues.apache.org/jira/browse/WW-3546
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors, Dispatch Filter, Plugin - JSON
> Affects Versions: 2.2.1
> Reporter: John Lindal
> Priority: Minor
>
> I have found it useful to be able to control "debugging mode" on a per-request basis. It makes it easier to track down problems reported in production that are hard to reproduce in a development environment.
> The places that I have found where it would be useful to control devMode are: Dispatcher.sendError(), JSONInterceptor, and DebuggingInterceptor. (Other uses of devMode are related to logging and config reloading, and that shouldn't be adjustable.)
> I've currently patched my copy of Struts 2.2.1 so each of the the above-mentioned code chunks checks an extra, static ThreadLocal variable that I added (in addition to the devMode member variable).
> 1) Is this the best solution?
> 2) Is this something that should be merged into the Struts 2 distribution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.