Opinion on grouper/shib options

[Cantor, Scott]

On 9/14/15, 12:16 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

>>
>>We have special bean processors that take care of that which you can find in the various Spring files (see the top of system/conf/global.xml for example).
>
>Sorry Scott, I am not sure what you are correcting me on, here.  My original course of action was to just declare a bean for my DataConnector in the conf/global.xml, and having just an empty constructor in that class.  Not only did it not instantiate, but the attribute-resolver complained that the data source ref id that I was referring to(the new bean's id), did not exist.

If it's in that file, I don't think you should have had to call setId. The bean's ID in the Spring file should be auto-set to be the component's ID in an internal IdP sense by this thing in global-system.xml:

 <!-- This BeanPostProcessor auto-sets identifiable beans with the bean name (if not already set). -->
    <bean id="shibboleth.IdentifiableBeanPostProcessor"
        class="net.shibboleth.ext.spring.config.IdentifiableBeanPostProcessor" />

That prevents a weird situation where a custom bean has to look like this:

<bean id="foo" p:id="foo" ... />

(or a case of needing to explicitly call setId in code, which is what I thought I saw you say)


>It was not until I wired the bean in a separate spring xml, and included that file location in the services.xml list for 'shibboleth.AttributeResolverResources', that 'all the little lights came on' and the resolver was attempting to initialize the connector.  On first try, with the empty constructor, the id property of the connector was null so I was getting an ComponentInitializationException.  That's when I added the #setId call to the connector's constructor, and the resolver is now working without error.

I thought we auto-injected that BeanPostProcessor into the service contexts, but I'm not seeing it, so that probably explains why it broke there. If you add that same bit of boilerplate at the top of your custom beans resource file, you're good to go without having to remember to call setId.

-- Scott