Re: Persistent Search

2013-07-24 Thread Kiran Ayyagari
On Tue, Jul 23, 2013 at 1:45 PM, Kiran Ayyagari kayyag...@apache.orgwrote:




 On Tue, Jul 23, 2013 at 1:09 PM, Alexander Broekhuis 
 a.broekh...@gmail.com wrote:

   what is the scope you set in the search request? is your baseDN
  cn=testadd,ou=system?
 

 The entry has been added using:

 AddRequestImpl requestImpl = new AddRequestImpl();

  requestImpl.setEntry(new DefaultEntry(

 cn=testadd,ou=system,// The Dn

 ObjectClass: top,

 ObjectClass: person,

 cn: testadd_cn,

 sn: testadd_sn

 ) );

  AddResponse add = con.add( requestImpl);

 Does that mean the basedn is  cn=testadd,ou=system?

 The search is done using: new Dn(cn=testadd,ou=system),
 (objectclass=*),
 SearchScope.ONELEVEL

 The search scope is onelevel, changing this to object I do see the
 existing
 entry and the delete event, but not the add. Perhaps I am using the wrong
 scope, but I didn't expect to see A(Scope.OBJECT) the existing entry and
 the delete but not the add, or B (Scope.ONELEVEL): not the existing entry
 but the delete and add.

 I _think_ there is an issue with evaluating scope in psearch, I will
 check and let you
 know

 have fixed this[1] in trunk

if you want to build from sources do:

1. svn co
https://svn.apache.org/repos/asf/directory/apacheds/trunk-with-dependenciestrunk

2. cd trunk

3. mvn clean install -DskipTests
(remove -DskipTests if you want to run tests, but this takes around 15
minutes to build)

[1] https://issues.apache.org/jira/browse/DIRSERVER-1874


 
  
   --
   Met vriendelijke groet,
  
   Alexander Broekhuis
  
 
 
 
  --
  Kiran Ayyagari
  http://keydap.com
 



 --
 Met vriendelijke groet,

 Alexander Broekhuis




 --
 Kiran Ayyagari
 http://keydap.com




-- 
Kiran Ayyagari
http://keydap.com


Re: Persistent Search

2013-07-23 Thread Kiran Ayyagari
On Tue, Jul 23, 2013 at 12:13 PM, Emmanuel Lécharny elecha...@gmail.comwrote:

 Le 7/23/13 8:31 AM, Alexander Broekhuis a écrit :
  To make this work, we need to let the API codec service about the
  corresponding control's factory class
  by setting the system property
  System.setProperty(
 StandaloneLdapApiService.DEFAULT_CONTROLS_LIST,
 
 
 org.apache.directory.api.ldap.codec.controls.search.persistentSearch.PersistentSearchFactory);
 
  Thanks, I'll try this.
 
  But somehow I don't yet fully understand the principles behind the API. I
  am not familiar with LDAP and/or JNDI, so perhaps I am missing some basic
  knowledge. Would it make sense to read more about LDAP and JNDI to
  understand how I should use the API?

 Don't read anything about JNDI : this API is pure crap, and diverge from
 LDAP so much that it will make you having headaches...

 Reading a few things about LDAP would help though.

 OTOH, we should update the site to give more information to users ;-)
 
  The problems I am now running into are:
  I am trying to make a listener like class that tracks a certain DN. So I
 am
  using a persistent search and for each entry I can call a callback
 method.
  But I don't know how to tell what the ChangeType of a new entry (updated
  cursor) is.

 With the PersistentSearch, you will be get back any entry that has been
 modified, but you won't know which modification has been done on the
 entry. For that, you have to check the EntryChange control that is
 returned with any SearchResultEntry.
 
  What I could find was that I need to use the EntryChange control from the
  response. To do this I now use setReturnECs on the PersistentSearch
  control, but I can't find any controls on the Response I get from the
  Cursor. What am I doing wrong?

 We are chekcing if ther eis not a bug in this area...


 this is again due to not having the proper control factory, replace
earlier property setting with
System.setProperty( StandaloneLdapApiService.DEFAULT_CONTROLS_LIST,

org.apache.directory.api.ldap.codec.controls.cascade.CascadeFactory, +

org.apache.directory.api.ldap.codec.controls.manageDsaIT.ManageDsaITFactory,
+

org.apache.directory.api.ldap.codec.controls.search.entryChange.EntryChangeFactory,
+

org.apache.directory.api.ldap.codec.controls.search.pagedSearch.PagedResultsFactory,
+

org.apache.directory.api.ldap.codec.controls.search.persistentSearch.PersistentSearchFactory,
+

org.apache.directory.api.ldap.codec.controls.search.subentries.SubentriesFactory
);

then you will be able to see the complete details of the control's value,
otherwise you see only the OID
and below are few more properties if you ever want to use other/extra
controls

System.setProperty( StandaloneLdapApiService.EXTRA_CONTROLS_LIST,

org.apache.directory.api.ldap.extras.controls.ppolicy_impl.PasswordPolicyFactory,
+

org.apache.directory.api.ldap.extras.controls.syncrepl_impl.SyncDoneValueFactory,
+

org.apache.directory.api.ldap.extras.controls.syncrepl_impl.SyncInfoValueFactory,
+

org.apache.directory.api.ldap.extras.controls.syncrepl_impl.SyncRequestValueFactory,
+

org.apache.directory.api.ldap.extras.controls.syncrepl_impl.SyncStateValueFactory
);

System.setProperty(
StandaloneLdapApiService.DEFAULT_EXTENDED_OPERATION_REQUESTS_LIST,

org.apache.directory.api.ldap.extras.extended.ads_impl.cancel.CancelFactory,
+

org.apache.directory.api.ldap.extras.extended.ads_impl.certGeneration.CertGenerationFactory,
+

org.apache.directory.api.ldap.extras.extended.ads_impl.gracefulShutdown.GracefulShutdownFactory,
+

org.apache.directory.api.ldap.extras.extended.ads_impl.storedProcedure.StoredProcedureFactory,
+

org.apache.directory.api.ldap.extras.extended.ads_impl.pwdModify.PasswordModifyFactory
);

System.setProperty(
StandaloneLdapApiService.DEFAULT_EXTENDED_OPERATION_RESPONSES_LIST,

org.apache.directory.api.ldap.extras.extended.ads_impl.gracefulDisconnect.GracefulDisconnectFactory
);


 --
 Regards,
 Cordialement,
 Emmanuel Lécharny
 www.iktek.com




-- 
Kiran Ayyagari
http://keydap.com


Re: Persistent Search

2013-07-22 Thread Kiran Ayyagari
On Mon, Jul 22, 2013 at 4:15 PM, Alexander Broekhuis
a.broekh...@gmail.comwrote:

 Hi all,

 I am looking into ApacheDS and the Api to work with the server. I am trying
 to implement some of the examples used in the documentation, but there are
 several small things differently with the latest release? Eg a
 connection.search(String, String,) returns a EntryCursor, and not a
 SearchCursor, whereas a connection.search(SearchRequest) does return a
 SearchCursor.
 So a first question, why this difference? And what way is the
 best/preferred way to do a search etc?

EntryCursor is used when you expect only entries (not referrals) in the
results
SearchCursor gives you all entries and referrals (if present) as well


 My next question is about PersistentSearch, how do I do this? For example,
 I have the following code:
   SearchRequest searchRequest = new SearchRequestImpl().setBase( new Dn(
 ou=system ) ).setFilter( objectclass=*)).setScope(
 SearchScope.ONELEVEL).addControl( new PersistentSearchImpl() );
   SearchCursor cursor = con.search(searchRequest);

   while (cursor.next()) {
 Response response = cursor.get();
 System.out.println(((SearchResultEntry)response).getEntry());
   }
   cursor.close();

 When I run this code without the Control it returns the entries I expect,
 but with the Control, it somehow blocks at cursor.next(). I am not even
 sure this is the correct way to do a persistent search, I can't find any
 documentation on this at all. Also, when I have a persistent search, how
 can I get a call that the result has been changed? Eg entry added/removed
 etc.

 you get the results asynchronously, i.e, you leave the loop running and it
will wait for
the incoming results, just make sure you increase the timeout either at the
connection (setTimeOut)
level or in the SearchRequest (setTimeLimit())

 Thanks,

 --
 Met vriendelijke groet,

 Alexander Broekhuis




-- 
Kiran Ayyagari
http://keydap.com


Re: Persistent Search

2013-07-22 Thread Emmanuel Lécharny
Le 7/22/13 1:09 PM, Kiran Ayyagari a écrit :
 On Mon, Jul 22, 2013 at 4:15 PM, Alexander Broekhuis
 a.broekh...@gmail.comwrote:

 Hi all,

 I am looking into ApacheDS and the Api to work with the server. I am trying
 to implement some of the examples used in the documentation, but there are
 several small things differently with the latest release? Eg a
 connection.search(String, String,) returns a EntryCursor, and not a
 SearchCursor, whereas a connection.search(SearchRequest) does return a
 SearchCursor.
 So a first question, why this difference? And what way is the
 best/preferred way to do a search etc?

 EntryCursor is used when you expect only entries (not referrals) in the
 results
 SearchCursor gives you all entries and referrals (if present) as well

At this point, I'm wondering if it makes sense to not use a SearchCursor
in any case ?



 My next question is about PersistentSearch, how do I do this? For example,
 I have the following code:
   SearchRequest searchRequest = new SearchRequestImpl().setBase( new Dn(
 ou=system ) ).setFilter( objectclass=*)).setScope(
 SearchScope.ONELEVEL).addControl( new PersistentSearchImpl() );
   SearchCursor cursor = con.search(searchRequest);

   while (cursor.next()) {
 Response response = cursor.get();
 System.out.println(((SearchResultEntry)response).getEntry());
   }
   cursor.close();

 When I run this code without the Control it returns the entries I expect,
 but with the Control, it somehow blocks at cursor.next(). I am not even
 sure this is the correct way to do a persistent search, I can't find any
 documentation on this at all. Also, when I have a persistent search, how
 can I get a call that the result has been changed? Eg entry added/removed
 etc.

 you get the results asynchronously, i.e, you leave the loop running and it
 will wait for
 the incoming results, just make sure you increase the timeout either at the
 connection (setTimeOut)
 level or in the SearchRequest (setTimeLimit())

It would be cnvenient to have a persistentSearch() method hich returns a
future, and you should have a non-blocking method to get a result when
called, beside a blockig method.

Wdyt ?


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 



Re: Persistent Search

2013-07-22 Thread Kiran Ayyagari
On Mon, Jul 22, 2013 at 4:52 PM, Alexander Broekhuis
a.broekh...@gmail.comwrote:

 Hi,

 Thanks for the quick reply.


  
   you get the results asynchronously, i.e, you leave the loop running and
  it
  will wait for
  the incoming results, just make sure you increase the timeout either at
 the
  connection (setTimeOut)
  level or in the SearchRequest (setTimeLimit())
 

 Thanks for the explanation. So this means I have to create a thread myself
 to handle changes etc. Also, in my test, existing entries are not part of
 the result, is this intended? In other words, I have to do a normal query
 for existing entries, and the persistent one for changes?

 by setting the changesOnly flag ( setChangesOnly(false)) to false you can
get all the
entries as well (but appears that this flag is ignored now )

 Is there any helper class in the Ldap API which makes this simpler for me
 to use? For example a listener model with callback methods?

no, but take a look at the searchAsync() method and see if the returned
Future can be
used according to your use


 --
 Met vriendelijke groet,

 Alexander Broekhuis




-- 
Kiran Ayyagari
http://keydap.com


Re: Persistent Search

2013-07-22 Thread Kiran Ayyagari
On Mon, Jul 22, 2013 at 5:01 PM, Kiran Ayyagari kayyag...@apache.orgwrote:




 On Mon, Jul 22, 2013 at 4:52 PM, Alexander Broekhuis 
 a.broekh...@gmail.com wrote:

 Hi,

 Thanks for the quick reply.


  
   you get the results asynchronously, i.e, you leave the loop running
 and
  it
  will wait for
  the incoming results, just make sure you increase the timeout either at
 the
  connection (setTimeOut)
  level or in the SearchRequest (setTimeLimit())
 

 Thanks for the explanation. So this means I have to create a thread myself
 to handle changes etc. Also, in my test, existing entries are not part of
 the result, is this intended? In other words, I have to do a normal
 query
 for existing entries, and the persistent one for changes?

 by setting the changesOnly flag ( setChangesOnly(false)) to false you can
 get all the
 entries as well (but appears that this flag is ignored now )

To make this work, we need to let the API codec service about the
corresponding control's factory class
by setting the system property
System.setProperty( StandaloneLdapApiService.DEFAULT_CONTROLS_LIST,
org.apache.directory.api.ldap.codec.controls.search.persistentSearch.PersistentSearchFactory);


 Is there any helper class in the Ldap API which makes this simpler for me
 to use? For example a listener model with callback methods?

 no, but take a look at the searchAsync() method and see if the returned
 Future can be
 used according to your use


 --
 Met vriendelijke groet,

 Alexander Broekhuis




 --
 Kiran Ayyagari
 http://keydap.com




-- 
Kiran Ayyagari
http://keydap.com