You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Kiran Ayyagari <ka...@apache.org> on 2013/07/22 13:09:28 UTC
Re: Persistent Search
On Mon, Jul 22, 2013 at 4:15 PM, Alexander Broekhuis
<a....@gmail.com>wrote:
> 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
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 1:45 PM, Kiran Ayyagari <ka...@apache.org>wrote:
>
>
>
> On Tue, Jul 23, 2013 at 1:09 PM, Alexander Broekhuis <
> a.broekhuis@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
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 1:45 PM, Kiran Ayyagari <ka...@apache.org>wrote:
>
>
>
> On Tue, Jul 23, 2013 at 1:09 PM, Alexander Broekhuis <
> a.broekhuis@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
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 1:09 PM, Alexander Broekhuis
<a....@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
> >
> > >
> > > --
> > > Met vriendelijke groet,
> > >
> > > Alexander Broekhuis
> > >
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
>
>
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>
--
Kiran Ayyagari
http://keydap.com
Re: Persistent Search
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 1:09 PM, Alexander Broekhuis
<a....@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
> >
> > >
> > > --
> > > Met vriendelijke groet,
> > >
> > > Alexander Broekhuis
> > >
> >
> >
> >
> > --
> > Kiran Ayyagari
> > http://keydap.com
> >
>
>
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>
--
Kiran Ayyagari
http://keydap.com
Re: Persistent Search
Posted by Alexander Broekhuis <a....@gmail.com>.
> > 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.
>
> >
> > --
> > Met vriendelijke groet,
> >
> > Alexander Broekhuis
> >
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Persistent Search
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 12:51 PM, Alexander Broekhuis <a.broekhuis@gmail.com
> wrote:
> Hi,
>
>
> > this is again due to not having the proper control factory, replace
> > earlier property setting with
> >
>
> Thanks for the list, I already tried adding the ChangeFactory, but that
> wasn't enough... With your list I can now get the control and the
> ChangeType!
>
> Some more questions on this topic:
> When using ChangesOnly(false), for all existing entries no EntryChange
> control is available, I assume this is by design and it is save for me to
> assume that entries with no EC control are existing entries? Ie, for me I
> would handle those as "added".
>
yes
>
> Also: I now have an entry with DN: "cn=testadd,ou=system", when starting a
> PersistentSearch with exactly that query I don't see an existing entry, but
> I do see the removal and (re)addition of the entry. This seems strange, I'd
> expect the existing entry to be listed as well.
>
> what is the scope you set in the search request? is your baseDN
"cn=testadd,ou=system"?
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>
--
Kiran Ayyagari
http://keydap.com
Re: Persistent Search
Posted by Alexander Broekhuis <a....@gmail.com>.
Hi,
> this is again due to not having the proper control factory, replace
> earlier property setting with
>
Thanks for the list, I already tried adding the ChangeFactory, but that
wasn't enough... With your list I can now get the control and the
ChangeType!
Some more questions on this topic:
When using ChangesOnly(false), for all existing entries no EntryChange
control is available, I assume this is by design and it is save for me to
assume that entries with no EC control are existing entries? Ie, for me I
would handle those as "added".
Also: I now have an entry with DN: "cn=testadd,ou=system", when starting a
PersistentSearch with exactly that query I don't see an existing entry, but
I do see the removal and (re)addition of the entry. This seems strange, I'd
expect the existing entry to be listed as well.
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Persistent Search
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 12:13 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> 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
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Jul 23, 2013 at 12:13 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> 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
Posted by Emmanuel Lécharny <el...@gmail.com>.
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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Persistent Search
Posted by Alexander Broekhuis <a....@gmail.com>.
> 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?
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.
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?
The system property in combination with setChangesOnly(false) works, so I
am now seeing existing entries as well.
Again, thanks for your help, and any pointers to some more documentation
are also welcome!
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Persistent Search
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jul 22, 2013 at 5:01 PM, Kiran Ayyagari <ka...@apache.org>wrote:
>
>
>
> On Mon, Jul 22, 2013 at 4:52 PM, Alexander Broekhuis <
> a.broekhuis@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
Re: Persistent Search
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jul 22, 2013 at 5:01 PM, Kiran Ayyagari <ka...@apache.org>wrote:
>
>
>
> On Mon, Jul 22, 2013 at 4:52 PM, Alexander Broekhuis <
> a.broekhuis@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
Re: Persistent Search
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jul 22, 2013 at 4:52 PM, Alexander Broekhuis
<a....@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 )
> 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
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jul 22, 2013 at 4:52 PM, Alexander Broekhuis
<a....@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 )
> 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
Posted by Alexander Broekhuis <a....@gmail.com>.
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?
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?
--
Met vriendelijke groet,
Alexander Broekhuis
Re: Persistent Search
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 7/22/13 1:09 PM, Kiran Ayyagari a écrit :
> On Mon, Jul 22, 2013 at 4:15 PM, Alexander Broekhuis
> <a....@gmail.com>wrote:
>
>> 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