Schema support for Spring <beans> in LDAP/RDBMS config

Rod Widdowson rdw at steadingsoftware.com
Tue Feb 11 04:06:29 EST 2014


Daniel wrote the DataConnector parsers and is the expert here, so I'd wait
for his definitive response. 

Meantime, I have been wondering whether the solution to this isn't to
entirely exbed the Spring parsing and extend the schema instead.

We have already talked about the need for a new type of DataConnector which
is purely a reference to a one defined in a different file (we needed this
for the StoredID C14N as well as database pooling).  All the services
support multiple input resources and so splitting Spring/Shibboleth schema
over two files isn’t a big deal, further the writing of the element into a
ByteOutputStream just so that it can be parsed back again worries me in some
undefinable manner.  Maybe this discussion has defined it.

To be explicit I'm suggesting dropping embedded spring and only allowing
indirect connectors.  So instead of

<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory">
     <beans>
        <bean/>
         <Stuff/>
    </beans>
<resolver:DataConnector/>

We would go
Attribute-resolver.xml

<resolver:DataConnector id="myLDAP" xsi:type="dc:Indirect"
springId="SpringLDAP"/>

Spring-beans.xml

 <beans>
    <bean id="SpringLDAP"/>
</beans>

The Service infrastructure allows this (see attribute-params-config.xml) at
no cost and there is something appealing about separating the two languages.

I will note that Daniel is in the middle of a large refactor of this stuff
to deal with IDP-357 and IDP-354 so more changes here right now might be
'contra-indicated'.



More information about the dev mailing list