Adding attribute functionality to testbed

Tom Zeller tzeller at dragonacea.biz
Sat Nov 2 04:00:10 EDT 2013


>> Absolutely...
>>>
>>> Rod, do you think you could take some time soon and start laying out beans
>>> and config files for the resolver (and maybe filter) code in the testbed?

Lesson 1 : avoid emailing during trick-or-treating.
Lesson 2 : avoid emailing after trick-or-treating...

Anyway, I see this task as more of an AND than an OR, meaning Rod take
point and stay in touch with me, please.

Earlier, Rod reminded me about the AttributeResolverService in
idp-attribute-resolver-spring. The methods getAttributeResolver() and
resolveAttributes() are orthogonal, only one should exist. The
interface-averse design seems to require getAttributeResolver(), but
the suggestion I was following was to proxy or mimic the methods of
the wrapped AttributeResolver via resolveAttributes(). But without an
AttributeResolver interface, I do not see clearly how to inject the
AttributeResolverService anywhere expecting an AttributeResolver. I
have been assuming I was looking at the design incorrectly.

So, as I understand it, services.xml will instantiate a singleton
AttributeResolverService bean with id "AttributeResolverService", but
at the moment I do not know the Spring syntax for how the singleton
AttributeResolver bean with id "AttributeResolver" will be returned
from the "AttributeResolverService". I imagine it is straightforward.
And I assume singletons.

The question I have, which I mentioned to Rod, is why we have to
manage the lifecycle of the AttributeResolver bean at all, meaning why
do we need our Service class. So while Rod is looking at Resources,
and their reloading, I asked him to keep an eye out for bean lifecycle
management. Maybe others, Brent, Daniel, Marvin, might hopefully know
more.

I just wonder why we are managing bean lifecycle by hand when we might
should let Spring do it. So that is why I say this is an AND task,
because I have some fairly fundamental learning to do regarding
Spring.

Also, as a sort of aside, if the AttributeResolverService provided
resolveAttributes() instead of getAttributeResolver(), than the
AttributeResoverService in idp-attribute-resolver-spring is the API
and AttributeResolver in idp-attribute-resolver-api is not, which is
confusing. So, maybe I misunderstood from the beginning.


More information about the dev mailing list