Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggested Enhancement: Expose DumpFullDebugStackTrace to be set dynamically/statically. #20

Open
GoogleCodeExporter opened this issue Mar 27, 2015 · 4 comments

Comments

@GoogleCodeExporter
Copy link

What version of the product are you using? On what operating system?
1.16 on RHEL 6.5/Windows 7/OS X

Please provide any additional information below.

I have made a modification to expose Properties.DumpFullDebugStackTrace so it 
can be modified dynamically at runtime. We find it extremely useful but are not 
free to set the system property and restart at will. 

I've attached an IntelliJ patch file for reference. This was done from the 
current trunk/1.17-SNAPSHOT source. Simply put, I just removed the "final" 
designation on the property and added a static setter in the Properties class.

This is just a suggestion. If you feel there's a better implementation please 
use it. I feel others could benefit from this type of enhancement as well.

Thanks.

Original issue reported on code.google.com by dsch...@parchment.com on 3 Jun 2014 at 5:31

Attachments:

@GoogleCodeExporter
Copy link
Author

Would it be OK to have different values of this parameter allowed for different 
Connection objects? 
Or do you want to be able to change the value of this parameter for a given 
Connection object, without acquiring a new one?

If it is the former, then this enhancement could be part of a big update I plan 
for Property management. 

Original comment by frederic...@gmail.com on 4 Jun 2014 at 11:35

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I'm ok with having it for different Connection objects, though the simple use 
case is that I just set it true while the system is running (while having 
jdbc.sqltiming set at the DEBUG level), acquire the logs with stacks which I'm 
after, and toggle it back to false (and set jdbc.sqltiming back to FATAL) so 
that the logs don't become too large to reasonably work with. 

If your plans for the Property management incorporate a way to do this, that's 
great and I look forward to it.

Thanks

Original comment by dsch...@parchment.com on 5 Jun 2014 at 10:11

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Original comment by frederic...@gmail.com on 7 Oct 2014 at 4:07

  • Changed state: Accepted
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Original comment by frederic...@gmail.com on 1 Feb 2015 at 3:42

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant