Hi Sebastian, et all
thanks a lot for your opinions.
I want to make some things clear to me (and all others interested).
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
<Start Time="Tue Oct 28 14:28:24 2003"/>
<Duration="0.020 sec"/>
<User="cn=admin,o=Fasr"/>
<IP="127.0.0.1"/>
<ConnID ="1953"/>
<Operation="SEARCH"/>
<Version="3"/>
<MessageID="4302"/>
<Base Obj="ou=ctscApplicationDataRepository, o=Fasr"/>
<Scope="onelevel"/>
<Filter="(&(objectclass=ctscPropertyDefinition)(ctscObjectClass=User))"/>
<Size Limit="0"/>
<Time Limit="0"/>
<Deref Alias="never"/>
<Types Only ="no"/>
<Req Attr="all"/>
<Found Entries="2"/>
<Found Attrs="5"/>
<entryresult>
<attribute name="dn" value="cn=admin,o=fasr">
<attribute name="cn" value="admin">
</entryresult>
<Controls="0"/>
<Bytes Received="136"/>
<Bytes Returned ="41"/>
<Abandoned ="no"/>
<Result Code ="0 (success)"/>
</binary>
I suppose that the assertions will take place on the data given in the
"binary" tag, so this will make parsing the result easy.
I migth add some more "headers" and format this like a http response, so
mayby the listeners will show the data then?
(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.
I suggest that we use the official ldap error codes (as far as JNDI supports
them).
questions:
Is this the way to proceed?
Do we need more fields in the result set?
Do we define something html like, or do we use an official DTD for ldap
(dsml or something)?
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.
Awaiting all yor comments,
Dolf
----- Original Message -----
From: "BAZLEY, Sebastian" <[EMAIL PROTECTED]>
To: "'JMeter Developers List'" <[EMAIL PROTECTED]>
Sent: Thursday, November 13, 2003 13:34
Subject: RE: LDAP suggestions:
> To follow up my own message: I've updated the ldap client search code to
> detect if a search returns any results or not, and updated the sampler to
> generate different codes for success (200), no results (201), and failure
> (500). User-defined searches work OK for me, but YMMV.
>
> More work is needed to improve the error codes and messages, and to look
at
> what should go in the requestData and responseData fields, but hopefully
> there is enough information to be able to use the sampler and response
> assertions in some real tests. Please be aware that the result codes may
> need to change.
>
> Unfortunately, the Gump builds are not working at present, because of an
> error in a pre-requisite build. I've reported the bug, but in the
meantime,
> if anyone cannot build from CVS and wants a compiled version, please let
me
> know off-list, and I can see about sending you a copy.
>
> S.
> -----Original Message-----
> From: BAZLEY, Sebastian
> Sent: 12 November 2003 16:59
> To: JMeter Developers List
> Subject: LDAP suggestions:
>
>
> It looks as though the SampleResult fields are not being utilised fully by
> the LDAP code.
>
> It seems to me that the response code could be used to distinguish various
> kinds of success - for example, using HTTP-style values:
>
> 2xx - search succeeded, some results found
> 2yy - search succeeded, no results found
> 4xx - some kind of error
> 5xx - another kind of error
>
> I leave it to others more familiar with LDAP as to what exact form the
error
> codes should take (and what the corresponding messages should be), but I
> think this approach would fit in with the rest of JMeter, and would allow
> the use of a Response Assertion to convert a search with no results into a
> failed sample.
>
> ==
>
> The other area where the sample result could be better used is the
response
> Data. This is currently set to "success full" - but does not appear in the
> Tree View, because the DataType is not being set to TEXT.
>
> The sampler could have another field to specify which attributes to
return.
> [Is there a sensible default set of attributes that applies to all/most
LDAP
> implementations? I don't know.]
>
> ==
>
> If these suggestions make sense, I am happy to help with updating the code
> in CVS.
>
> --
> Sebastian Bazley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
