DO NOT REPLY [Bug 15826] New: - New Test Component type: Extractors

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15826>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15826

New Test Component type: Extractors

           Summary: New Test Component type: Extractors
           Product: JMeter
           Version: Nightly (Please specify date)
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Main
        AssignedTo: jmeter-dev@jakarta.apache.org
        ReportedBy: jsalvata@atg.com


>From an e-mail I wrote a while ago:

[...]

I also would like to see limited scripting functionality
replacing/complementing the current ${functions} with ECMAScript
expresions. This would also address Mike's wish to have more complex
parsing..

Being more specific, I was thinking about a simplification of the
functions functionality. A function currently produces a value from the
current test execution context, which includes the results of the last
request and little more. This causes difficulties, for example, if you
want to use a piece of info in a response two requests later. The
solution was this "variable-names" stuck to the end of the function call
so that you can (re-)use that value later on -- but it's all tied with
strings.

My idea is to create a new kind of component, an "Extractor", which
would receive samples and extract data from them, placing the results in
variables. Similar to Assertions, these extractors would most often be
placed inside a Sampler, but it could make sense to put one in a
controller if it needs to repeat the extraction for each sampler in there.

Once you have this, you can almost eliminate the concept of ${functions}
and almost stick to ${variables} -- although being able to use
expressions on the variables, possibly including real functions, would
be great. I say "real functions" because the current ones are very badly
named, since their results depend (almost exclusively) on things other
than their parameters, so they are not functions in a proper sense.

A side advantage of this "Extractor" idea is that complex stuff like
regular expressions could go into their own field in a GUI form, instead
of being embedded in a longer text.

Possible extractors:
- Regexp extractor
- Cookie extractor
- Session id extractor
- Form field extractor
[...]

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>