Bugzilla – Full Text Bug Listing
| Summary: | need to establish links/relationships between profiling types and agents/launch configuration types | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Eric Labadie <labadie> |
| Component: | TPTP | Assignee: | amehrega |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P1 | CC: | ashishp, qiyanli |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_78473.html | ||
| Whiteboard: | |||
| Bug Depends on: | 90754 | ||
| Bug Blocks: | |||
|
Description
Eric Labadie
Mapping profiling sets to agent types is not a complete solution since all profiling agents, PI or J2EE, share the same profiling type. I am upgrating the defect to a feature so that we make sure the solution for this problem is getting enough consideration and go to the right channels for a complete design. Actually, the profiling types don't apply to the J2EE request profiler.. the profiling set selection page (overview tab) is disabled in this case to avoid user confusion. The profiling types for memory, coverage, and execution have hardcoded piAgent options in them that don't apply to the J2EE request profiler. The design I was considering was more along the lines of linking profiling types to launch configs / agent types.. and only profiling sets with the right profiling types would show up. It wouldn't be a 1-1 mapping, as some profiling types could be shared among different agents / launch configs. This is only one of the problems with the design, there are numerous other things lacking, like page display notification, querying the profiling type UIs for error messages and whether or not they are complete (finish button enabled), etc. The sizinf for this feature is 8 weeks and there are not enough resources to be included into the 3.3 or 4.0 plan if not already committed; moving feature to 4.1 update priority Deferring from 4.1 as per the official 4.1 enhancement plan. http://eclipse.org/tptp/home/project_info/featureplans/features.php?source=All&project=All&release=4.1&file=TPTPFeatures_4.1.xml Setting to next release. This one is important for us. One more thing to add about this one. Consider the case where we are not profiling live, but importing data from some persistence mechanism like a database, and populating the model with this data.. where there is no agent to do the real-time equivalent (i.e. you can only view historical data, no live data). In this case we would still want to show a profiling type, possibly a special one that only appears when importing this kind of data. However, we do not want the profiling type to show up for any of the agents because you can't get this kind of data live; so I should be able to define a profiling type not linked to any launch config or agent, however still be able to show it in the Profiling Monitor. This might be assumed from the feature description, but I just wanted to make sure the feature would allow this. Targeting to 4.2i1. Owners plese adjust for any exceptions by targeting to 4.2i2. This feature along with many other features will be knocked out by 93212, which is targeted to i2. I'll target this one to i2 as well. Fix in cvs. Refer to figure 2.2 in http://www.eclipse.org/tptp/home/documents/tutorials/datacollection/launch-extensions/extending-launch-configuration.html for the relationship of the entities involved. Closing. |