Community
Participate
Working Groups
We would like to store some extra information about classes in the model. Specifically, we want to mark a java class as, say, an EJB, or a Servlet, so that we can categorize the data in our UI. This is the specific requirement we are looking for, but we'll probably want to make it very generic so that you can add any arbitrary properties (key/value pairs?) to perhaps more than just classes. Currently we are using method parameters to store this information, where the parameter value is an index into the "master" table of entries, specified as agent options. This is a little strange, so we'd like a cleaner solution.
In 4.1 we will have the annotation at package/class/method level, you can use them to add any extra information to thes compoents. Please close this feature if the annotation support is enough for your use cases. Parameter/return values are part of methodEnry/Exit events, you will need to send those events in order to get parameter/return values in the model (also the collection mode name should include EXECUTION_FULL word.
It seems the notion of component level tracing is what is being asked for. Curtis are you looking to be able to understand high level component flows from within a detailed trace for example?
Right. We want to show a topology of all the components in the application system, who calls who, and some totals/averages on each component. Having annotations would be one way to do this, but now that I think about it probably not the best way. I should have stated the actual requirement, and not a possible solution. Thanks for clarifying. (renamed the enhancement)
One of the intended usage for trace annotation would be to tag the workload/high level interactions in a detailed trace (also comming from raw trace). Basically tag each package(class or method) with the component name/type. We also plan to provide a wizard to create derived agents by applying filters (at workbench site) which will contain a high level interaction. Harm,Curtis do you think this would not be enough for the component level tracing use case?
If you're asking if it's possible to do component level trace with annotations, I think the answer is yes. The question is whether this is a good way to do it or not. I would think a better way might be to introduce a new entity in the model for components, rather than making it a property of its sub-elements. This would be like making classes a property of methods, rather than having them as separate entities. And in the same way that the loaders add up the totals for the classes (e.g. base time), it could go one step further and do it for the component? Rather than having to do this as a post-processing step when a viewer is opened. Just a thought.
We already discussed this approach and we found that the annotation and derived agents could be a better alternative, especially because if you start to build a component level interaction in the model you will probably end up duplicating all levels in the trace (that's exactly what we achieve through the derived agent, which initially would be build using filters). Our current approach doesn't preclude you to compute the statistics at component level in the loaders, the aggregated values would be stored in a derived agent which will represent the high level interaction for a set of agents. I would like to understand what extra information will you need in a component entity that you could not represent with package/class/method/annotation? Also would be helpful if you can add more context around what you mean by a component, in an incomprehensive way I see the component as being defined by a set of packages (seen as namespace, modules etc).
So perhaps a component in this case is much like a logical container of some set of events that have been captured. Some other tools in this space do manage this as a filtered view over more granular data. In those cases the component, may be defined as a department or a web service or a java package. In each case it can be represented as a set events that as a unit have a set of external interactions, aka "boundary events". I think some sort fo rooting collection per component in the model makes sences as does have the concept in filter specifications.
Batch update of all TPTP platform enhancements that are not part of 4.2 approved plan. Set version to "future" and target milestone to "--".
Adding 130160 as dependent. Technical details of 130160 help to implement this defect.
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.
