Bugzilla – Full Text Bug Listing
| Summary: | Java Tracing | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Martin Robertson <mchr3k> |
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | curtis.windatt.public, mchr3k, Michael_Rennie, ndsilva, pwebster, remy.suen, swanj |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Martin Robertson
(In reply to comment #0) > -- A new post launch action which uses the Attach API > (http://download.oracle.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html) So this feature would only work for the HotSpot JVM, is this correct? (In reply to comment #1) > (In reply to comment #0) > > -- A new post launch action which uses the Attach API > > (http://download.oracle.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html) > > So this feature would only work for the HotSpot JVM, is this correct? I assume from the package name that is correct. However the actual Java Agent API (java.lang.instrument) is presumably available across all JVMs so the idea of a new launch option should work across all JVMs. I have to admit that I do all my work with the Sun JVM so I haven't tested with anything else. (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > -- A new post launch action which uses the Attach API > > > (http://download.oracle.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html) > > > > So this feature would only work for the HotSpot JVM, is this correct? > > I assume from the package name that is correct. However the actual Java Agent > API (java.lang.instrument) is presumably available across all JVMs so the idea > of a new launch option should work across all JVMs. > > I have to admit that I do all my work with the Sun JVM so I haven't tested with > anything else. Actually a quick google suggests that at least the IBM JVM has some level of support in its own platform specific package: http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.user.aix64.60/user/attachapi.html I am starting to think of the code changes which would be necessary for the "at launch" approach. There are two approaches which I have identified. 1) Add a new "Trace" launch mode to the existing "Run", "Debug" etc. This would use extension point org.eclipse.debug.core.launchModes to define the new mode. org.eclipse.debug.core.launchDelegates would be used to define how to launch appropriate existing launch configuration types (e.g. Java Application) in this new mode. I'm not sure how the actual VM argument would be injected. 2) Add a new config option to appropriate existing launch configuration types (e.g. Java Application). I'm not sure what extension point would be used to expose UI for the new config option. I'm not sure how the actual VM argument would be injected. (In reply to comment #4) > I am starting to think of the code changes which would be necessary for the "at > launch" approach. There are two approaches which I have identified. > > 1) Add a new "Trace" launch mode to the existing "Run", "Debug" etc. > This would be a good place to start. That way you can play with the integration and work out any kinks, then in the future we could look at supporting mixed-mode launching, which would allow you to just extend the normal Java Application launch configuration. Another option might be to just add a new launch configuration type (for run and debug) that reused the Java Application stuff but added support for tracing - this approach would give you full control over the UI for the tab group and the shape / values in the launch configuration > > I'm not sure what extension point would be used to expose UI for the new config > option. > If you wanted to extend the Java Application tab group you can use the org.eclipse.debug.ui.launchConfigurationTabs extension point to add your own custom tab to the tab group - you could add a new 'Tracing' tab to the Java Application tab group for example. If you wanted to go the route of a new launch configuration type you would want to use the following extension points: org.eclipse.debug.core.launchConfigurationTypes org.eclipse.debug.core.launchDelegates org.eclipse.debug.ui.launchConfigurationTabGroups > I'm not sure how the actual VM argument would be injected. Provided you extended / reused the code for a Java Application launch configuration, you could add them manually on the VM arguments block for the time being while you play around with it, and work on an automated scheme later. You could also add any entries to the IJavaLaunchConfigurationConstants.ATTR_VM_ARGUMENTS value in the launch configuration and they will automatically be added to the VM arguments during launching. Thanks for this feedback. My next concern is how to package this as a plugin. In the past I have written Eclipse plugins and packaged them by pressing "Build All" on a feature project. However, this produces a jar for the plugin. This plugin will need to add a -javaagent VM argument which points at an intrace-agent.jar. I know some eclipse plugins are installed as an unzipped directory. How do I make this happen for my own plugin? Can you point me at the right docs to generate a path to the jar in the install directory of a plugin? OK so I have ported my existing UI to Eclipse. You can try out the new functionality by downloading the following archived update site. https://github.com/downloads/mchr3k/org.intrace/intrace.ecl.site.zip This is a pretty rough implementation but should hopefully work for you. This plugin includes the following. - New launch mode "InTrace" - Supported launch types: Java Application, Junit Test - An "InTrace" launch is a modified "Run" launch -- InTrace agent is loaded using a JVM argument -- New InTrace editor is opened to connect to the agen -- Launched program is initially paused until you press a "Start" button in the InTrace editor -- Once the InTrace editor has been closed there is currently no way to re-open it How to use: 1) Install the plugin 2) Launch an application or junit test in InTrace mode 3) Click "Select Classes..." and enter some include/exclude patterns to define which classes you want to trace 4) Click "Start Program" 5) Trace should be written to the Output tab Let me know what you think. I know there is a LOT of polish which could still be added. This page contains the documentation for the Eclipse UI. https://github.com/mchr3k/org.intrace/wiki/Docs:-Eclipse-UI-%28Alpha%29 The target milestone has been set to Eclipse 3.8. Does that mean this feature will definitely be included with Eclipse 3.8? If so, when will I realistically be able to get my design/code reviewed? I'm sure you are very busy with the Eclipse 3.7 release right now. (In reply to comment #9) > The target milestone has been set to Eclipse 3.8. Does that mean this feature > will definitely be included with Eclipse 3.8? Not exactly. It means we/I will review / work on it for inclusion in 3.8. I tagged it more-so so I would not forget about it. > If so, when will I realistically be able to get my design/code reviewed? I am planning to do it in the coming weeks. > I'm sure you are very busy with the Eclipse 3.7 release right now. Yes. I have now released V0.0.0.2 of my plugin with the following enhancements: - Open a new InTrace editor from an existing launch - right click the launch and select "Open InTrace Output". - Lots of code cleanup. - Proper error handling - any errors should now be properly logged/shown to the user. You can download this update and all future updates using this update site URL: http://intracesite.appspot.com/ The URL for the docs on GitHub is now https://github.com/mchr3k/org.intrace/wiki/Docs:-Eclipse-UI Sorry about the spam, the correct link is actually https://github.com/mchr3k/org.intrace/wiki/Docs:-InTrace-Eclipse-Plugin (In reply to comment #13) > Sorry about the spam, the correct link is actually > https://github.com/mchr3k/org.intrace/wiki/Docs:-InTrace-Eclipse-Plugin I had a chance to play with the tracing support, and while I think it is pretty cool, I also think it is better left as a 3rd party add-on (something like JaCoCo, etc). My biggest fear (and reason for not wanting to make it part of JDT debug) is that it is a lot of code and we currently do not have a lot of committer resources to spend on support / bug fixing for this new addition. Thoughts? Thanks for taking the time to look at this. In an ideal world I think it would be great if JDT supported all of the following "out of the box": - Code Coverage - Profiling - Tracing However, given you have limited resources I agree that it makes sense to keep InTrace separate. The only thing I would suggest is that you add the integration of these features into core JDT onto a wishlist document for future work. In the event that you find some resources in the future it would be nice to think you might reconsider integrating InTrace. Please let me know if you have any feedback about InTrace itself. (In reply to comment #15) > The only thing I would suggest is that you add the > integration of these features into core JDT onto a wishlist document for future > work. In the event that you find some resources in the future it would be nice > to think you might reconsider integrating InTrace. > I created a wiki page for us to keep track of such items: http://wiki.eclipse.org/Debug/Plan/Future > Please let me know if you have any feedback about InTrace itself. The tooling was simple to use and the integration was good, I thought it just needed a bit more polishing in the presentation. It would also be good if there was some way to organize the tracing(s) that you do get, to help with the analysis of them. Marking as wontfix, since there are no immediate plans to add this to JDT debug. (In reply to comment #16) > (In reply to comment #15) > > > The only thing I would suggest is that you add the > > integration of these features into core JDT onto a wishlist document for future > > work. In the event that you find some resources in the future it would be nice > > to think you might reconsider integrating InTrace. > > > > I created a wiki page for us to keep track of such items: > http://wiki.eclipse.org/Debug/Plan/Future > I have linked to some related projects here: http://mchr3k.github.com/org.intrace/related.html Some of these tools aren't free but it would still be good to get some inspiration from them. In particular, I would love to see functionality like this in JDT: http://www.chrononsystems.com/ You should probably add a link to Eclipse TPTP to the Future plans page - perhaps parts of TPTP should become part of the default JDT project. However, I would personally suggest that TPTP needs some work to simplify it and make it easier to get started with. > > Please let me know if you have any feedback about InTrace itself. > > The tooling was simple to use and the integration was good, I thought it just > needed a bit more polishing in the presentation. Do you have any specific suggestions about polishing the UI? I have already been through several iterations with the UI but would love to get some more ideas about how to make it simpler. http://mchr3k.github.com/org.intrace/img/connectedgui-v4.jpg http://mchr3k.github.com/org.intrace/img/connectedgui-v3.jpg http://mchr3k.github.com/org.intrace/img/connectedgui-v2.jpg http://mchr3k.github.com/org.intrace/img/connectedgui.jpg > It would also be good if there was some way to organize the tracing(s) > that you do get, to help with the analysis of them. The UI lets you save the trace output as a text file - are you imagining a View to provide quick access to historical traces? (In reply to comment #17) > Do you have any specific suggestions about polishing the UI? > Specific, no. It just felt like there was a lot going on all at once, especially once the trace starts filling the central text area. Perhaps it would be better to run the trace as a job and just present the user with the end result, rather than run it all in a view? Maybe even present the results as a search result (or something similar)? > The UI lets you save the trace output as a text file - are you imagining a View > to provide quick access to historical traces? Yes, and some way to group / reorganize a given trace - i.e. a tree view representation of the text file (or something similar). |
