Shibboleth Developer's Meeting, May 24, 2013
Attendees: Brent, Daniel, Ian, Marvin, Rod, Scott, Tom
Call Administrivia
Next call is next Friday.
60 to 90 minute call window.
Brent
Finishing up remaining TODOs in message processing code as well as java-shib-testbed.
As documented in Web Flow, when a flow reaches an end-state, if a view-state is not rendered the default behavior is to redirect to beginning of flow. Need to mark response as completed at end of flow, RequestContext.getExternalContext().recordResponseComplete().
Daniel
Ian
Marvin
Rod
Scott
Task dies if ThreadExecutor throws an exception ? In vt-ldap, if a periodic validator is configured and the host is unavailable and an exception is thrown, the thread will disappear.
Scott : Should v2 depend on ldaptive ?
Daniel : Would take some work.
Make a note of issue, and defer making changes until we see further need to.
Ian
Standards (metadata extensions, long term, some sort of delegated registry of URIs) work, documentation. More metadata aggregator use cases, make additional code public or donate maybe.
Marvin
Busy.
Rod
- Attribute Filtering. After discussion with Tom, completed refactoring (unfortunately some may need unrefactoring)
- Started on the the rest of the "Policy" type predicates.
- Design note for AttributeInMetadata and AttributeInRequest under construction.
R : Capture what @ThreadSafe means ?
S : Need more annotations, as discussed. The standard should be that a thread-safe object requires absolutely no thought about concurrence of any kind.
Scott
Development time this week spent on SP fixes / testing, updating libraries for Windows build, and coordinating with some third parties on the timing of the next release.
Tentative release date for 2.5.2 is now June 18th.
Will be prepping packages and builds this week and next for testing. Once things are ready to go, I'll get back to V3 work. Will probably look at pulling in Marvin's suggestions on the storage API next.
Tom
AI : Tom should send note regarding next steps for security configuration.
AI : Roadmap next steps.
AI : API changes
Refactoring idp-attribute-filter-api, looks like a return to v2, with some differences. Not sure why v3 diverged originally, let us avoid design regressions.
Be deliberate when changing API artifacts. Special svn notifications ?
Continue to refactor "MatchFunctor" to "Matcher" and its evaluatePolicyRule(AttributeFilterContext) to matches(AttributeFilterContext).
Q : "What does a Matcher do?"
A : A Matcher might (1) match an attribute filter context and/or (2) get values of an attribute in the attribute filter context which match the Matcher.
As mentioned in Javadoc, a base AbstractMatcher class could require concrete implementations to provide just getMatchingValues(), since a default matches() implementation could iterate over the Attributes in the AttributeFilterContext and return true the first time getMatchingValues() returns a non-empty set. Not optimal, of course.
So, MatchFunctor might exist in the schema only.
As mentioned on a previous dev call, for consistency, I thing "filtering" should be refactored to "filter" in Java class and package names, and the AttributeFilteringEngine should become AttributeFilter. To match the AttributeResolver maybe AttributeFilterer is more appropriate, but no.
Readlock on AttributeFilterService.filterAttributes() ?
Change the schema too ?
Topics
Decisions
Coding convention : getLdapUrl or getLDAPURL ?
You will have to be logged in to register a vote, otherwise nothing will appear below this in the page.