You are viewing a plain text version of this content. The canonical link for it is here.

Posted to jmeter-dev@jakarta.apache.org by Norbet Reilly <nr...@gmail.com> on 2006/08/28 08:40:09 UTC

Improvements related to LDAP Sampler

Hi,

I have made the following improvements to the JMeter LDAP support
which I wanted to share with the list:
    1. Changed LDAP sampler to:
        a. sort search results (by DN), attributes for each result (by
id) and values (by toString()) for searches returning less the a
configured constant (1000) entries. Having a stable ordering allows a
new class of response assertion detailed below.
        b. fix bugzilla 40103 (extra "</operation>").
        c. use StringBuffer instead of '+' for search results where
there may be big numbers of results to be marshalled to XML.
        d. Added extra <searchresults> tag and nested <dn> ...
<attribute> stuff inside the <searchresult> tag. This was because the
existing structure is not very XSD/JAXB etc friendly, and there seems
no good reason why it shouldn't be.
    2. Changed ResponseAssertion.java to:
        a. support a new "Pattern Matching Rule" called "Equals" which
does a direct string comparison between the response and the first
"Patterns To Test" string which has been entered. This is not directly
tied to the LDAP sampler but requires a sampler to output fields in a
stable order to be used effectively. It is better for simple
comparing against a full response then "Matches" because there is no
need to consider quoting of special regex chars.
        b. log.info() information about failed assertions so that the
reason for failures is clear immediately from the log, including the
assertion's name. In the case of the new "Equals" assertions, a small
diff showing markers for initial matching sequence (if any) and final
matching sequence (if any) is also logged, so that the non-matching
text is aligned in the middle for easy identification.

These changes greatly improve the ease with which you can script an
LDAP interaction and then use the results seen in the View Results
Tree to turn the interaction into a unit test asserting correct
behaviour (after suitable manual review of course). This was
particularly attractive to me as two serious problems were observed
with the GUI as it stands:
    1. The attribute table presented "LDAP Extended Request (ALPHA)"
"Add tests" requires that you hit return on every text field entered
(rather then tabbing/clicking off it) or the modified value is not
saved even though it appears to be. This was problematic as I was
cutting and pasting a number of existing LDIF files into these
windows, and the problem only became apparent when I went to run my
test and found bogus data in virtually all of the fields I'd entered.
    2. The "Patterns to Test" table on the Response Assertion" screen
doesn't deal well with long single line patterns, in that the whole
line becomes obscured by a scrollbar rendering ineditable (except by
tricks like trying to scoll to the end of the line adding a number of
un-needed blank lines/clicking off/clicking back so that the added
blank lines coincide with the scrollbar when it is rendered).

I have a patch I can submit if the project is interested, and can
enter the issues above into bugzilla if given the go-ahead. As this is
my first posting to the JMeter dev list I just wanted to check exactly
what the appropriate protocol is.

My patch is against a downloaded 2.2 source, which I notice doesn't
include any .svn directories; is this by design or accident as it
means a somewhat painful (and quite possibly error-prone) manual
merging of changes over a freshly checked out SVN dir if someone works
on a patch before realising that no SVN dirs are present.

Thanks for your guidance/feedback...

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org