Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Java: Finding Bugs, Fixing Bugs in IBM Domino Designer and XPages

3,253 views

Published on

Writing Java code? Of course you are. Paul and Julian will demonstrate some tools and techniques for tracking down real or potential bugs in your code, and show you ways that you can investigate your Java environment if you think something is acting strangely. We will focus largely on Java in the context of IBM Domino Designer, but these techniques should be applicable to other contexts (like Eclipse) as well.

Published in: Technology
  • Be the first to comment

Java: Finding Bugs, Fixing Bugs in IBM Domino Designer and XPages

  1. 1. Java: Finding Bugs, Fixing Bugs in IBM Domino Designer and XPages Julian Robichaux Senior Software Engineer, panagenda Paul T. Calhoun Senior Software Engineer, panagenda MWLUG 2014
  2. 2. Your Speakers • Julian Robichaux - Developer at panagenda, an Austrian based IT management software provider - Purveyor of nsftools.com - Writer of open-­‐source (and commercial) software - Speaker at Lotusphere since 2006, many LUG and View conferences in various countries - Doing almost exclusively Java and Eclipse development (often Notes related) for the past few years - Not as pretty as Paul Calhoun, but still easy on the eyes
  3. 3. Your Speakers • Paul T. Calhoun - I have been working with Lotus/IBM technologies for the past 25 years. - I have been certified in both Administration and Development on every major release of Notes/Domino since release 3. - My focus has always been on training and enablement of Administrators and Developers, but I also provide mentoring and consulting services. - Most recently I have been focused on XPages consulting, training and enablement. - When not working, my passion is spending all my spare time with my awesomely wonderful grand-­‐kids. (WARNING: I have pictures !)
  4. 4. Agenda • Debugging - Java Agents - XPages • Logging • Using FindBugs • Using JConsole and Dump Analysis • Q & A
  5. 5. Debugging Java Agents • There are several steps to enable a Java debugger to debug a Java agent running on the Notes client: - Enable Java debugging on the Notes client. - Enable debugging in the agent (compile code with debug info). - Add thread sleep commands to the Java agent. - Set breakpoints in the Java code. - Create a Debug Configuration in the Java Perspective in Domino Designer to connect to the Notes client. - Add the agent source to the debug configuration. - Run the debugger in Domino Designer client. - Start the Notes agent to debug. - Debug the code as needed. • Detach the debugger from Notes.
  6. 6. Enable Debugger • Follow these steps to enable remote Java debugging on the Notes client: - Choose Tools | Java Debugging Preferences from the menu. - In the Java Debugging Preferences dialog, choose the appropriate types of agents to debug and set the port values. - Port values must be unique when enabling debugging for more than one type of agent. - Click [OK] to save the settings and close the dialog.
  7. 7. Enable Debugger • Variables in the NOTES.INI file are added to reflect the port settings and agent type selections - JavaDebugClientForeground=1 - JavaDebugClientForegroundPort=8701 - JavaDebugClientScheduled=1 - JavaDebugClientScheduledPort=8702 - JavaDebugClientWebPreview=1 - JavaDebugClientWebPreviewPort=8703 ! • Notes must be restarted for the NOTES.INI changes to take effect. Click [OK] when prompted to restart Notes. • Exit and restart Notes.
  8. 8. Enable Agent for Debugging • Follow these steps to enable debugging for a Java agent: - Open the Java agent's Properties. - From the Basics tab of the Properties view • Enable the 'Compile Java code with debugging information' option. • This will add line numbers and information about variables to the compiled code to allow the agent to be debugged.
  9. 9. Enable Breakpoints • Follow these steps to add breakpoints to an agent: - Open the agent in Designer. - Breakpoints can be added by either: • Right-­‐clicking in the left margin of the code editor and choosing • Toggle Breakpoint • Double-­‐clicking in the margin next to the code to add/remove the breakpoint. - The breakpoints are indicated by a blue dots in the bar beside the editor margin.
  10. 10. Create Debug Configuration • This only has to be done once • In Designer: - Click the down arrow next to the blue “Debug” icon - Choose “Manage Debug Configurations”
  11. 11. Create Debug Configuration • In the Debug Configurations Dialog - Right Click on “Remote Java Application” - Choose “New”
  12. 12. Set Debug Configuration • Provide a Name • Change Port to Port set in Notes.ini - Default is 8701 but can be any open port • Click “Apply” and “Close” to save • Click “Apply” and “Debug” to start the debugger listening on the defined port
  13. 13. Switch to the Debug Perspective • If not already in the Debug Perspective a dialog will open prompting to switch to that perspective - Choose “Yes” • Optionally choose “Remember my decision” to suppress this dialog from popping up every time
  14. 14. The Debug Perspective
  15. 15. Debugging • The Code will stop at the first breakpoint • From there you can… - Inspect (and change) variables - Step through the code using the icons
  16. 16. Stop the Debugger • After the debugging session is complete the debugger is still “listening” on the open port • In the debug perspective make sure to “Disconnect” from the listening port to turn debugging off
  17. 17. Debugging Java XPages • If XPages make calls to Java Code elements then that Java code can be debugged using a similar process to debugging agents. • In order to debug Java code called by an XPage add the following lines to the notes.ini - JavaEnableDebug=1 - JavaDebugOptions=transport=dt_socket,server=y,suspend=n,addr ess=<port to listen on> • GOTCHA !! - If the previous ports are enabled for Java agent debugging then “connecting” to the port above will never work - Disable the Java Debug Ports and restart your Notes, Designer client prior to debugging Java called from XPages - Your firewall might block the port
  18. 18. Debug Configuration • Create a new Debug Configuration to “listen” on the port that was set in the notes.ini file • Preview the XPage to start the local web preview • Start the debugger
  19. 19. Execute XPage Action • Set breakpoints in the Java code to be debugged • In the XPage in the browser - Execute the action that will call the Java code • If not already in the Debug perspective you will be prompted to switch to that perspective • Step through your code reviewing the variable values at each breakpoint • Clear breakpoints and resume to end • Disconnect from Debugger when done.
  20. 20. WARNING DO NOT EVER ENABLE DEBUGGING ON A PRODUCTION SERVER
  21. 21. Demo
  22. 22. Agenda • Debugging - Java Agents - XPages • Logging • Using FindBugs • Using JConsole and Dump Analysis • Q & A
  23. 23. Logging
  24. 24. Logging Basics • System.out.println() is NOT logging! • Java has native logging classes - java.util.logging - There are other popular logging frameworks, which we will ignore for the sake of brevity - The native Java classes work just fine • The big picture: - Each bit of code can have its own logger, or loggers can be shared - Java manages all the different loggers being used - The logging level determines the severity of the message - Different handlers send messages to the console or to files
  25. 25. Logging Example create logger log to various levels easy Exception handling
  26. 26. Logging Levels • Log Levels, in order of highest to lowest: - SEVERE – serious failure, horrible stuff - WARNING – potential problem - INFO – informational, non-­‐technical - CONFIG – system/program configuration - FINE – simplest trace messages - FINER – medium trace messages - FINEST – detailed trace messages
  27. 27. Interpreting Levels • What level you use for your messages is a matter of personal preference. Here’s a general guideline/suggestion: - Showstopping issues go to SEVERE - Errors your admin (and nosy users) should see go to WARNING - Unobtrusive “heartbeat” kinds of messages go to INFO - Start and stop messages go to CONFIG - Debug info goes to FINE/ER/EST, with FINEST being very tedious and verbose • These are “trace” levels • Generally only enabled for troubleshooting purposes
  28. 28. Log Handlers • Typical log handlers write to either the console or a file • There are default handlers for different contexts - Java agents: Java console (client), server console (server) - XPages: server console (server), files (client and server) - Plugins: OSGi console, files • Handlers also have levels - Console normally only displays log messages for SEVERE, WARNING, and INFO - File logs often display log messages for all levels
  29. 29. Logging Example where did this one go?
  30. 30. Log Levels and Output • Loggers often have a default level of INFO • This means that by default, any messages with a level lower than INFO will not be logged anywhere - So messages at level CONFIG and FINE/ER/EST will never be sent to a Handler because the Logger discards them • Messages get filtered by the Logger before they are passed to the Handler - Even a Handler at Level.FINEST will not get any FINE/ER/EST messages if the Logger is set to Level.INFO
  31. 31. Adjusting Log Levels • Adjusting log levels programmatically - setLevel() for Logger and Handler - This will cause a SecurityException! - You can get around this by editing jvm/lib/security/java.policy - permission java.util.logging.LoggingPermission "control" • Adjusting log levels with config files - Notes agents: {notes}jvmliblogging.properties - XPages: {domino}datadominoworkspace.configrcpinstall.properties
  32. 32. Example Log Level Adjustment Don’t forget the .level!
  33. 33. Logging Quirks in Notes • Prior to 8.5.3 FP2, Java logging in Notes worked just fine - Although logging in local agents didn’t log anywhere by default • In 9.0.0 and 8.5.3 FP2, FP3, and FP4 Java logging gave errors - java.security.AccessControlException - Add LoggingPermission to jvm/lib/security/java.policy • In 9.0.1 and 8.5.3 FP5, Java logging worked again - NEW: Local Java agents log to the Java Agent Console by default - NEW: if you still need the LoggingPermission so you can set custom Handlers or Levels, you also need to add a special SecurityPermission • http://www-­‐01.ibm.com/support/docview.wss?uid=swg21669594
  34. 34. XPages Log Output • XPages logging trace log files - Server 8.5.1: none, server console only - Server 8.5.2+: {domino}datadominoworkspacelogs • SEVERE messages still show up on the console too - XPiNC: {notes}dataworkspacelogs • Default logger level is WARNING, not INFO • Prior to 8.5.3, non-­‐logged XPages exceptions also used to show up in the trace logs. Now they are in {notes}dataIBM_TECHNICAL_SUPPORTxpages_exc_*.log - http://www-­‐01.ibm.com/support/docview.wss?uid=swg1LO66802
  35. 35. Viewing Trace Log Files • Trying to view the trace log files as raw XML is… painful • A better way is to right-­‐click them in the “logs” folder and open them in a browser - There is an XSLT file that will format them nicely for you • HOWEVER, if the client or server is still running, the XSLT file won’t work because the closing XML tag is missing - Make a copy, open in a text editor, and add a closing </CommonBaseEvents> tag to the end. Then open in a browser. - Make sure you open the copy from within the “logs” folder; otherwise the XSLT file will not be found - Sometimes log messages don’t show up immediately in the log files! Everything gets flushed when you shut down the server.
  36. 36. XPages Logging Example
  37. 37. XPages Logging Example
  38. 38. XPages Logging Example
  39. 39. Logging Best Practices • Use the same logger for your entire package (maybe even your entire library) • Most messages should be logged to FINE/ER/EST; don’t clutter up the console with INFO messages • Log actions, but not every step of a method or every single get/set – logging is NOT a replacement for a debugger • DO NOT EVER log sensitive data - Personal user information, passwords, system “secrets” - “No one will ever look at those anyway” is bad security
  40. 40. Agenda • Debugging - Java Agents - XPages • Logging • Using FindBugs • Using JConsole and Dump Analysis • Q & A
  41. 41. FindBugs • FindBugs is a program that uses static analysis to look for bugs in Java code. - Current version is 3.x • Source and Documentation at - http://findbugs.cs.umd.edu/eclipse • Latest version of FindBugs CANNOT be installed into DDE natively - Either install in a stand alone version of Eclipse - Use FindBugs for Domino Designer from OpenNTF - FYI, This is a version 2.x implementation of FindBugs • http://www.openntf.org/main.nsf/project.xsp?r=project/FindBugs %20for%20DominoDesigner
  42. 42. FindBugs • Available as an Eclipse plug-­‐in, install instructions at - http://findbugs.cs.umd.edu/eclipse • Agents contained in an NSF are not “readable” during the FindBugs analysis. - The agent code will need to be exported and imported into Eclipse for analysis.
  43. 43. Change FindBugs Properties • Change the FindBugs Properties to show all bugs
  44. 44. Running FindBugs • In Domino Designer open the Package Explorer view - If this view is not in the current perspective, either • Switch to the XPages perspective • Add it to the current working perspective • Right click over the code folder to be analyzed and choose “Run FindBugs”
  45. 45. FindBugs Perspective • After analyzing code, switch to the FindBugs perspective • Or add the Bug Explorer view to the current perspective • Remediate the found bugs
  46. 46. Demo
  47. 47. Agenda • Debugging - Java Agents - XPages • Logging • Using FindBugs • Using JConsole and Dump Analysis • Q & A
  48. 48. My Notes Client is Slow! • Troubleshooting slow performance is tricky - How do you define “slow”? - How do you know it’s your code and not something else? - Task Manager only tells you about high-­‐level processes • Much easier to troubleshoot on a client, rather than a server - Not disruptive to restart - Easy to change parameters - Crash at will! • Whenever possible, port your Java code to a local Notes agent or a local XPage for troubleshooting
  49. 49. A Tale of Two VMs • The Notes client actually has two Java VMs for running code - Java agents - The rest of the Notes client (including local XPages) • The VM for Java agents is adjusted with: - Notes.ini settings - {notes}jvmlib properties files • The VM for everything else (on the client) is adjusted with: - {notes}frameworkrcpdeployjvm.properties - {data}workspace.configrcpinstall.properties
  50. 50. JConsole • JConsole is a tool for monitoring performance and resource usage in a running JVM - http://docs.oracle.com/javase/6/docs/technotes/guides/ management/jconsole.html • I wrote an article on setting this up for local XPages and plugins (non-­‐Java-­‐agents) here: - http://www.socialbizug.org/blogs/2ec5d0ed-­‐ d04e-­‐4b18-­‐9610-­‐9819fcebca79/entry/ using_jconsole_to_monitor_your_ibm_notes_client • Quick demo…
  51. 51. JConsole Screenshot
  52. 52. JConsole for Local Java Agents • To use JConsole to monitor local Java agents, there’s a trick - Add JavaUserOptionsFile to your Notes.ini file: • JavaUserOptionsFile=c:IBMNotesjava.options.txt - In your Java options file add these lines: • -­‐Dcom.sun.management.jmxremote.port=9876 -­‐Dcom.sun.management.jmxremote.ssl=false -­‐Dcom.sun.management.jmxremote.authenticate=false • Connect JConsole to the jmxremote.port you defined - This port won’t be active until AFTER you run a Java agent - Make sure nothing else is using that port - Make sure the firewall allows that port to be used
  53. 53. JavaUserOptionsFile
  54. 54. Analyzing Dump Files • If your Notes client (or Domino server) crashes due to a Java problem, it will usually generate a core dump file - default location is workspacelogs - Just a text file - Shows what threads were running, system info, etc. • IBM Thread and Memory Dump Analyzer does a good job of parsing the core dump file for you - https://www.ibm.com/developerworks/community/groups/ service/html/communityview?communityUuid=2245aa39-­‐ fa5c-­‐4475-­‐b891-­‐14c205f7333c - run like this: java -Xmx500m -jar jca455.jar
  55. 55. IBM Memory Dump Analyzer
  56. 56. Heap Dumps • Heap Dumps are a snapshot of the JVM threads and processes at a specific point in time, while it’s running - Like a slice of what you see in JConsole • Used for: - Tracking down memory leaks - Finding high-­‐memory-­‐use objects (and arrays) - Finding objects that are unexpectedly still in memory • IBM Heap Analyzer is a nice tool for viewing the information - https://www.ibm.com/developerworks/community/alphaworks/tech/ heapanalyzer - http://www-­‐01.ibm.com/support/docview.wss?uid=swg27006624&aid=1
  57. 57. How to Generate a Heap Dump • Generating a Heap Dump file (no crash required!) - Domino XPages • tell http xsp heap dump • XPages Toolbox ( http://www.openntf.org/p/XPages%20Toolbox ) - Notes Client (from a command prompt) • notesframeworkrcprcplauncher.exe -­‐com.ibm.rcp.core.logger#dump heap -­‐dumps heapdump • writes to {data}workspacelogsheapdump.###.phd by default • You can also do a core (thread) dump with: • notesframeworkrcprcplauncher.exe -­‐com.ibm.rcp.core.logger#dump threads -­‐dumps javacore - Java Agent • com.ibm.jvm.Dump.HeapDump(); • writes to {notes}frameworkheapdump.###.phd
  58. 58. IBM Heap Analyzer Screenshot
  59. 59. IBM Heap Analyzer Screenshot
  60. 60. IBM Heap Analyzer Screenshot 2318 Notes Documents 2318 Notes Items 1 Notes View 1 Notes Database 1 Notes Session 1 ??? ——————————— 4640 NotesWeakReferences
  61. 61. Agenda • Debugging - Java Agents - XPages • Logging • Using FindBugs • Using JConsole and Dump Analysis • Q & A
  62. 62. Q & A Questions? Anyone?
  63. 63. THANK YOU Julian Robichaux panagenda jrobichaux@panagenda.com MWLUG 2014 Paul Calhoun panagenda paul.calhoun@panagenda.com

×