[Server/Client] Entry / Exit point definition for methods (low prio)

[doriancransac]

Will serve as a complement to the filters and the spawning of new trees starting at a given node.

Resulting gain : very powerful, additional filtering semantics for computation of sample percentages, among others.

@JSclient

[jeromecomte]

Implemented PoC in branch feature_entrypoints.

Use the following node filter to set an entry point: "entry:djigger" => this will define all the nodes matching the expression "djigger" as entry points.

As a consequence "not entry:djigger" as node filter combined with the stackfilter defines a kind of exit point.

Please look at the implementation (NodeFilter.java) if you want to understand how it works.

[doriancransac]

The "command line" approach is not a bad approach. I kind of like it.

What I had personally envisioned was something similar to the "Analize" click in agent mode, when popping a new window / frame. We could have an item in the right-click menu that says "Set as entry point in a new window" or something like that, which is more intuitive.

But the command line approach allows us to benefit from the operators, which is nice.

I guess they're both compatible anyways though.

One "bug" so far : since the "root object" remains the same, the result in terms of visualization in the block view is kind of crappy :

[doriancransac]

I think there might be another bug when combining the positive entry tags with the "and" and "or" operators:

In the first picture, I expect to not find anything (nothing matches that pattern), but instead I'm getting a match on the 2 last tokens.

In the second picture I should not see the top weblogic methods (weblogic.work package) and only start matching at ejb level.

The "not" operator alone and the "entry:x and not entry:y" seem to work fine however.

I'll send you my analysis session by email, since github refuses to upload my zip.

[doriancransac]

clearning milestone. we'll see later whether we want to finish this prior to 2.0 or not.