Opinion on grouper/shib options

[O'Dowd, Josh]

OK I see it now...  having a bean post processor in the same config xml is the ticket.

Additionally, I had chosen not to use /conf/global.xml to wire a custom DataConnector because I thought there might be adverse consequences to having the list, shibboleth.AttributeResolverResources include the global.xml file.  I therefore thought it prudent to create the attribute-resolver-spring.xml for my custom attribute-resolver-api classes for proper categorization, so to speak...  Granted, the IDs are only auto-set if there is a BeanPostProcessor wired in attribute-resolver-spring.xml, as well.

If this is all agreeable, I can confirm(per your earlier request that I test this theory) that native spring configuration of custom idp components does 'just work' and is a lighter weighted option than going the schema route.

Thanks.
-Josh

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, September 14, 2015 10:51 AM
To: Shib Users
Subject: Re: Opinion on grouper/shib options

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

>Just in case I was having a brain thing, I removed the explicit call to setId in the bean's constructor, and restarted...  I got the following exception:

Right. That's what the bean post processor fixes. If you get that with the bean defined in global.xml, I don't understand how, but that isn't where you ended up defining it I don't think.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net