Bugzilla – Full Text Bug Listing
| Summary: | Statically instrument an application without having to import probekit probes into the workspace | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Ashish Patel <ashishp> |
| Component: | TPTP | Assignee: | Ashish Patel <ashishp> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | labadie, mmings, nmehrega, popescu |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | housecleaned460 closed471 | ||
| Bug Depends on: | |||
| Bug Blocks: | 85646, 173202 | ||
|
Description
Ashish Patel
There's already a way of statically instrumenting classes/JARs that are not in your workspace. You can instrument any Java application on the command line as indicated in the following Help Content: Monitoring and profiling applications -> Collecting runtime data with user-defined probes -> Working with probes -> Collecting probe data: Special situations -> Collecting data with statically applied probes. Thanks for that info. Having the user use the command line is an advanced feature. We need to focus on giving good defaults on simple UI pieces that will help once the ARM instrumentation work is active. The goal is to have an easy way to instrument and deploy a statically instrumented application. This is why I have suggested adding an export wizard to start creating a seamless user experience for instrumenting applications. I look forward to your feedback. Ashish, I think you should be looking into dynamic probekit, since it offers a much richer user experiecne. It essentially allows you to do exactly what you've listed below via the launch configuration. You specify the probe you want to use, select your application (can be an external java app), and you specify which classes/methods to instrument via your filtering criteria. It then seamlessly instruments your application without modifying it on disk. I think what you're really asking for is an *instrumenting* wizard rather than an exporting wizard. You're not really exporting an existing file. You're instrumenting an application (i.e. modifying it) and saving the modified version else where. Perhaps, we should meet in person to get a better feel of your requirements. Assigning to Valentina as per discussion with Navid since this request is more of a UI feature. Had a discussion with Navid, and here are some notes: 1) The ARM tech preview doesn't have a complete use case for statistically instrumenting an application or class file, such that the instrumented asset uses the ARM Probes. a) The use case we want to design for allows a developer to statically instrument an application using ARM, then utilize that asset in the test-production or production environment. b) These environments don't necessarily have a developer/eclipse tools or a developer to operate TPTP tools. 2) We are requesting a wizard be made where a user can do a File->Export command and be taken through a series of wizard pages that helps the user select an application to instrument, select which ARM probes to use during instrumentation, and a location on the file system where the statically instrumented assets can be placed. 3) In addition, to the wizard, an extension point would need to be present allowing the extenders of TPTP and the ARM tech preview to contribute their own probekit probes. This way communities can provide a pre-built set of probes that can be used for static instrumentation. In addition, the probes used for static instrumentation aren't geared towards a specific nature - ie) ARM probes - but rather you can use a mixture of probes and instrument your application. This approach will help TPTP move away from having the probe source file always in the workspace and in a open project, and it reduces the burden on the user from knowning where the probe file is located in the plugins. 4) Navid mentioned that there are various flaws with the current workflow of static instrumentation, we should investigate those (perhaps he can list the defect/enhancement numbers to this defect). I can see this export wizard being reused in the current workflow of static instrumentation - ie) hitting two birds with one giantic stone. 5) The reason we can't use dynamic probekit is because we're not running/launching the application after instrumentation (we already have this case handled with the inital ARM contribution in TPTP 4.2). What we need is a way to use ARM probes to instrument an application and take the instrumented asset and deploy it to a different environment (as previously stated). I've put this into 4.2.1 since Matt and I are working on the ARM static use case in this release. This enhancement mentions some of the issues noted in bug 85646. Bug 85646 does a good job of explaining some of the problems and possible solutions for static instrumentation. Most use cases for static instrumentation can be replaced with dynamic instrumentation, which offers a richer user experience. I'm not sure how the PMC/PG wants to prioritize enhancements for static instrumentation. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |