Expected Behavior
public class InMemoryRelyingPartyRegistrationRepository
implements IterableRelyingPartyRegistrationRepository {
Current Behavior
public class InMemoryRelyingPartyRegistrationRepository
implements RelyingPartyRegistrationRepository, Iterable<RelyingPartyRegistration> {
Context A mess develops when you start adding custom implementations that are also iterable, and/or writing e.g. custom login pages that need to iterate through all registrations. Especially if you're trying to compose multiple repositories because they need different behaviour,
You either have to resort to unchecked casts, or unpleasant generics like <T extends RelyingPartyRegistrationRepository & Iterable<RelyingPartyRegistration>>.
I assume it's too late to make RelyingPartyRegistrationRepository extend Iterable<RelyingPartyRegistration> or to add a method that returns a Collection<RelyingPartyRegistration>?
Comment From: OrangeDog
More context: I'm composing multiple repositories because I'm implementing metadata refresh, and it's considerably easier if a RefreshableRelyingPartyRegistrationRepository is only responsible for a single URI, as each EntitiesDescriptor (or indeed HTTP response) can define its own caching and validity.
Although, as I've been typing this, I think it might be easier if I instead write a RelyingPartyRegistrationRepository adaptor for MetadataResolver. Then I don't have to reimplement everything that OpenSAML already does. You might consider adding that yourselves.
Edit: except you've made that difficult because OpenSamlMetadataRelyingPartyRegistrationConverter is not public.
Edit 2: also ChainingMetadataResolver does not implement IterableMetadataSource, but you cannot do anything about that.