----- Original Message ----- From: "Dolf Smits" <[EMAIL PROTECTED]> To: "JMeter Developers List" <[EMAIL PROTECTED]> Sent: Saturday, November 15, 2003 9:09 AM Subject: Re: LDAP suggestions:
[snip] > I understand from your changes, and from looking at what an http request > reports, that a proper sampleresult could look like the following: > <sampleResult timeStamp="1068885663705" dataType="text" threadName="Thread > Group-1" label="LDAP Request" time="70" responseMessage="OK" > responseCode="0" success="true"> > <binary>LdapV3 0 OK [snip] > </binary> The above looks like the contents of the log file, where functional testing mode has been selected. > I suppose that the assertions will take place on the data given in the > "binary" tag, so this will make parsing the result easy. Yes and no - Assertions act on the contents of various SampleResult fields, one of which is responseData. I'm not sure that parsing the result is always going to be "easy" ... > I migth add some more "headers" and format this like a http response, so > mayby the listeners will show the data then? The Listeners show what is in the SampleResult; different Listeners look at different fields. The Tree Listener shows the contents of most fields, but only shows the responseData if that is marked as containing Text. [The JavaTest Sampler allows you to set all the common response fields if you want to experiment.] > (or we might define/use an existing dtd and parse everything as corect xml, > but i have not enough experience with xml to get that properly defined. Parse? Do you mean encode? > I suggest that we use the official ldap error codes (as far as JNDI supports > them). I agree this would be best, but it does not seem to be all that easy to get at the LDAP error code. The Exception includes the error code as part of the output when converted using toString(), but there does not seem to be a method to return the code - it looks as though one would have to parse the string. But I've not looked all that deeply into this - perhaps there is a nice and easy way to get the code. [Either way, the responseCode should be number, and the responseMessage should be the toString() value.] > > questions: > Is this the way to proceed? > Do we need more fields in the result set? Yes - nothing useful is returned at the moment. But that is fixable. Could we not just return all the fields which are defined by the filter criteria? But it still needs to be possible to return a success/fail indication without needing to return any data. > Do we define something html like, or do we use an official DTD for ldap > (dsml or something)? The existing SampleResult structure was defined for HTTP, as were the Listeners. It may be necessary to extend the structure to cater for LDAP, as the resultData field has no structure. It would probably be useful to extend the SampleResult to include an optional Headers object; this could also prove useful for HTTP requests. The fields could just be xml-encoded in the resultData as I think you are suggesting. But this could make Response Assertions regexes trickier to code, in the same way that it can be tricky to specify searches for a specific instance of some text in an HTML document. Now if the exisiting Response Assertion was extended to include some kind of DOM matching facility, e.g. using JDom, then it ought to be possible to pick out individual parts of the response more easily than using regexes. This would also be useful for HTML responses, but these might need to use a different parser. > > If we continue, i'm willing to start working on this, I assume that lots of > the code will be the same for the current ldap sampler, as well as my own > extended ldap sampler, so we might combine the efforts. > S. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
