[midPoint] New Kerberos connector, paging support questions

[Radovan Semancik]

Hi,

Thank you. Kerberos connector would be a nice addition to 
ConnId-compatible connector collection.

I agree that the paging behavior is quite strange. It is partially given 
by the fact that there is no count() operation in ConnId. However, the 
GUI frameworks need to know the number of all entries in the search to 
correctly display the paging information. Particularly Wicket framework 
expect two separate operations: count and search. But that is not the 
case with ConnId. The paging mechanism in ConnId allows to pass the 
information about the number of entries as a product of the search. 
Hence two search operations. First one is used to get the number of all 
results, second one is used to get the actual results for the displayed 
page.

This is not ideal. And obviously it can be improved. We can improve that 
both on GUI (wicket) side in also in ConnId framework. However, we need 
funding for this work. As nobody has sponsored it yet and no major 
subscriber has raised this issue, this improvement is not yet planned. 
If you are considering sponsoring or subscription please do not hesitate 
to contact us.

BTW, if I remember correctly then ConnId offset starts at 1, not 0. 
Therefore offset=1 means request to return the entries from the beginning.

-- 
Radovan Semancik
Software Architect
evolveum.com




On 04/11/2017 01:51 PM, František Dvořák wrote:
> Hello,
>
> we're writing a connector at University of West Bohemia: native
> Kerberos connector based on JNI using MIT Kerberos 5 Admin library:
>
>    https://github.com/CESNET/kerberos-connector
>
> It is working quite good already. We don't have it in production
> though, and haven't made any release yet.
>
> I would like to ask about the paging support and executeQuery(). It
> seems it behaves quite strangely (using "Accounts" -> "Resouce" in
> resource details):
>
> * there are always two queries
> * initial query asks for page of size 1
> * subsequent query asks for the rest of the page, with offset 1
> * midPoint GUI swallows the first identity and shows only the
> identities from the second query
>
> Logs attached.
>
> Is there a bug in the connector code? The main connector class is
> located here: [1]
>
> The reconciliation seems work fine (the search without paging).
>
> Thank you,
>    Frantisek
>
> [1] https://github.com/CESNET/kerberos-connector/blob/master/src/main/java/cz/zcu/KerberosConnector.java
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170420/02199ea6/attachment.htm>