(Re-resend): About Native-Spring DataConnector definition and the version policy

[Rod Widdowson]

Apologies if this is the third (or more) copies of this (even if it is the
first of three).  My ISP appears to have gotten itself blacklisted, so I've
changed to a backup SMTP server and am resending.

TLDR: 

1) Do we have to move the DataConnectors to API? and if so how?
2) If so might we move to a full hybrid Attribute Resolver syntax?

At last week’s meeting I took an AI to write the impedance issues between
configuring the DataConnectors via the springResource attribute, and their
existence as implementations (not APIs).

The way that the springResource="path" attribute works is that the parser
causes a DataConnectorFactoryBean [1] to be used.  During this factory’s
getInstance() call the resource is parsed.  The factory then uses
introspection to match the setter types of the data connector against the
types of beans which have been parsed.  The types of beans that can be
provided up are listed in the documentation (for instance [2]).

So we have a partial exposure of the setters that the data connectors use.
The names of the beans can change but the types cannot.

My question was what that means for the implementation status of the
DataConnectors?  Do we have to bite the bullet and make them –api and if so
do we therefore have to move them to the –api tree?  I have a feeling that
they will bring a great deal of detritus over with them in terms of classes
that they require.  As an alternative we could add some sort of comment to
all of the DataConnnector setters to say "change the name but not the type".

Related to (and this is why this mail took so long) I want to open the
question again about hybrid native spring configuration.  It has been
possible for quite some time to configure Data Connectors entirely in native
spring (the move to services forced us to make changes to the outer parser
which in turn makes this possible) but to do this the native spring had to
be in a different file.

Over the weekend I worked out how to have hybrid custom files

<AttributeResolver 
>
   <DataConnector 
. >
   <AttributeDefinition 
>
   <beans xmlns=http://www.springframework.org/schema/beans” 
.>
</AttributeResolver>

It is a bit mucky in that involves some DOM surgery in the (new)
#registerBeanDefinitions() method of
SchemaTypeAwareBeanDefinitionDocumentReader. But it does work and the beans
are real peers of the attributes, they inherit from the environment and so
on.

Obviously exploiting this would have as a precondition moving the data
connectors out to api.  But I am not sure whether this would be in any way a
nicer configuration exercise.  The (for instance) LDAP connector is a pretty
complex beast and exposing all its internals might be scary for the neophyte
(yes, even more scary than the custom syntax)

FWIW my feeling is that 

- We probably want to move the DataConnectors to the api tree (if we do so
we need to do it properly).
- OTOH making yet another (albeit entirely backwards compatible) change to
the Attribute resolver language may not be the thing for now, since we may
be talking about changes the way that dependency is defined in V4.  Also
there is the whole thorny issue of having data connectors export "encoder
ready" attribute [3]

Rod


[1]http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-attribute
-resolver-spring/src/main/java/net/shibboleth/idp/attribute/resolver/spring/
dc/impl/DataConnectorFactoryBean.java

[2]
https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector#LDAPConne
ctor-Externally(Spring)DefinedContent

[3]
https://wiki.shibboleth.net/confluence/display/~rdw@iay.org.uk/Attribute+Flo
w+in+the+IdP+-+A+Discussion+document