setting SearchResultHandlers via Spring ?

[Tom Zeller]

Is it possible to set SearchResultHandlers using Spring ?

I tried

<bean id="ldapConfig"
class="edu.vt.middleware.ldap.LdapConfig"
p:searchResultHandlers="edu.internet2.middleware.ldappc.util.QuotedDnResultHandler,edu.vt.middleware.ldap.handler.FqdnSearchResultHandler"
...

which fails "Cannot convert value of type [java.lang.String] to
required type [edu.vt.middleware.ldap.handler.SearchResultHandler]".

It looks like there's custom code to support search result handlers in shib :

https://spaces.internet2.edu/display/SHIB2/vtldap3Upgrade

Thanks,
TomZ

P.S. I hope this is the right place to ask, at least according to the
3.3 readme :-)

[Daniel Fisher]

On Mon, Feb 15, 2010 at 3:22 PM, Tom Zeller <zell...@gmail.com> wrote:

Is it possible to set SearchResultHandlers using Spring ?

I tried

<bean id="ldapConfig"
 class="edu.vt.middleware.ldap.LdapConfig"
 p:searchResultHandlers="edu.internet2.middleware.ldappc.util.QuotedDnResultHandler,edu.vt.middleware.ldap.handler.FqdnSearchResultHandler"
 ...

which fails "Cannot convert value of type [java.lang.String] to
required type [edu.vt.middleware.ldap.handler.SearchResultHandler]".

I'm not a spring expert, but I had to define complex types as beans and use the <list/> element:

  <bean id="ldapConfig"
    class="edu.vt.middleware.ldap.LdapConfig"

    p:ldapUrl="ldap://directory.vt.edu:389/dc=vt,dc=edu"
    p:searchScope="SUBTREE">

    <property name="searchResultHandlers">
      <list>
        <bean id="fqdnSRH"
              class="edu.vt.middleware.ldap.handler.FqdnSearchResultHandler"/>
        <bean id="mergeSRH"
              class="edu.vt.middleware.ldap.handler.MergeSearchResultHandler"/>
      </list>
    </property>
  </bean>

There is probably a shorter notation for doing this, but it works.
 

It looks like there's custom code to support search result handlers in shib :

https://spaces.internet2.edu/display/SHIB2/vtldap3Upgrade

Not really, there are just certain pieces that make sense to define in the data connector XML schema.
In this case the only custom code is the wiring between the schema and the ldap data connector.

P.S. I hope this is the right place to ask, at least according to the
3.3 readme :-)

This is the right place to ask.
By the way, it's looking like 3.3 will get tagged within the next two weeks.
Do you have any comments/feedback on any of the release notes?
If so, please let me know.

--Daniel

[Tom Zeller]

I'd like to be able to configure the RangeSearchResultHandler
(http://code.google.com/p/vt-middleware/wiki/vtldapAD, but with an
LdapPool constructor arg) via Spring, but I don't know how to provide
the LdapPool object constructor arg.

I tried

<bean id="ldapFactory"
class="edu.vt.middleware.ldap.pool.DefaultLdapFactory"
p:connectOnCreate="false" >
<constructor-arg index="0" ref="ldapConfig"/>
</bean>

<bean id="ldapPool"
class="edu.vt.middleware.ldap.pool.SoftLimitLdapPool"
init-method="initialize"
p:blockWaitTime="1000">
<constructor-arg index="0">
<bean class="edu.vt.middleware.ldap.pool.LdapPoolConfig" />
</constructor-arg>
<constructor-arg index="1" ref="ldapFactory"/>
</bean>

<bean id="ldapConfig"
class="edu.vt.middleware.ldap.LdapConfig"

...
<property name="searchResultHandlers">
<list>
<bean id="rangeSRH"
class="edu.internet2.middleware.ldappc.util.RangeSearchResultHandler"
>
<constructor-arg index="0" ref="ldapPool"/>
</bean>
</list>
</property>
</bean>

which fails with

org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'ldapFactory': Requested bean is
currently in
creation: Is there an unresolvable circular reference?

Do you have any suggestions ? Would it be reasonable for
SearchResultHandlers to have access to the underlying Ldap connection
object ?

Thanks again,
Tom

[Marvin Addison]

> org.springframework.beans.factory.BeanCurrentlyInCreationException:
> Error creating bean with name 'ldapFactory': Requested bean is
> currently in
>  creation: Is there an unresolvable circular reference?
>
> Do you have any suggestions ?

I think we might want to review the component dependency graph in
order to avoid problems in use cases like this that are perfectly
reasonable.

In terms of a workaround, it seems to me the root of the circular
reference is referring back to the pool in RangeSearchResultHandler:

<constructor-arg index="0" ref="ldapPool"/>

Could you create two pools to break the circular reference?

M

[Tom Zeller]

I can try - the second pool would need the same configuration as the first.

The RecursiveSearchResultHandler is similar, it needs access to the
underlying Ldap object to perform supplementary searches. Perhaps this
kind of SearchResultHandler could have access to the Ldap connection
object ? or maybe the LdapConfig object so a new connection could be
created as needed ?

Thanks,
Tom

[Daniel Fisher]

I think that you're right Tom, the library should expose the Ldap object that was used to perform the search to the search result handler.
Right now I'm considering the following implementations:

1)
Update the SearchResultHandler interface to include a new method: setLdap(Ldap l);
Since the handlers were designed to be stateless, this setter would be invoked for every search operation performed.

2)
Create a new interface: StatefulSearchResultHandler extends SearchResultHandler which has the setLdap(Ldap l); method.
Basically the same as the previous, but allows implementers to avoid the setLdap method.
Would require the library to do class type checking in order to invoke the setter.

3)
Don't bother with changing the interface, have the library reflectively check if a method setLdap(Ldap l) exists on the search result handler and if so, invoke it.

Thoughts?

[Tom Zeller]

FWIW, I like the StatefulSearchResultHandler interface with the
setLdap(Ldap l) method for the reasons you mention, that not all
implementations need the Ldap object and to bring awareness to
statefulness. I'm wondering how it will work for paged searches, i.e.,
the state of the Ldap connection during paging.

I'm not a big fan of instanceof, so I think I like reflection, option
3, but I'm unable to make a convincing case; perhaps instanceof is
faster, I don't know.

In any case, if I understand correctly, the search() methods in
AbstractLdap will need to call handler.setLdap(this) before calling
handler.process(). That seems nice.

Thanks!
Tom

[Daniel Fisher]

Added http://code.google.com/p/vt-middleware/issues/detail?id=67

The implementation adds two new interfaces: ExtendedSearchResultHandler and ExtendedAttributeHandler
I went with Extended over Stateful because I thought stateful could imply some wrong ideas.
The Ldap class has been updated to auto-wire handlers of these types.

Take a look at the latest snapshot and let me know what you think.

--Daniel

[Tom Zeller]

> Added http://code.google.com/p/vt-middleware/issues/detail?id=67
>
> The implementation adds two new interfaces: ExtendedSearchResultHandler and
> ExtendedAttributeHandler
> I went with Extended over Stateful because I thought stateful could imply
> some wrong ideas.
> The Ldap class has been updated to auto-wire handlers of these types.
>
> Take a look at the latest snapshot and let me know what you think.

Looks clean. Just curious why you choose the word "Extended".

Thanks for doing this, it will make it easier to configure Active
Directory support via spring/xml, and for that matter, a properties
file.

Do you have a guess when 3.3 will be released ? We're looking at an
end of April-ish timeline for our next release, although last time we
delayed quite a few months :-)

Tom

[Daniel Fisher]

On Thu, Mar 11, 2010 at 9:09 PM, Tom Zeller <tze...@memphis.edu> wrote:

> Added http://code.google.com/p/vt-middleware/issues/detail?id=67
>
> The implementation adds two new interfaces: ExtendedSearchResultHandler and
> ExtendedAttributeHandler
> I went with Extended over Stateful because I thought stateful could imply
> some wrong ideas.
> The Ldap class has been updated to auto-wire handlers of these types.
>
> Take a look at the latest snapshot and let me know what you think.

Looks clean. Just curious why you choose the word "Extended".

Just that this interface does more than the base interface.
I imagine that future additional functionality will also go on this interface.
I freely admit that I'm bad at naming, so suggestions are welcome. :)

Do you have a guess when 3.3 will be released ? We're looking at an
end of April-ish timeline for our next release, although last time we
delayed quite a few months :-)

I'm guessing early to mid-April.
IMO it can be tagged at anytime, but just in case Shib or Grouper needs anything else I'll wait a few more weeks.

--Daniel
 

[Tom Zeller]

Thanks for everything. Attached is a revised RangeSearchResultHandler.

Tom