[MRESOLVER-305] Handle blocked state at connector level #228
Conversation
As blocked is really about block remote access. Locally cached things should not be affected, but current solution did not cover all execution paths. --- https://issues.apache.org/jira/browse/MRESOLVER-305
| { | ||
| if ( repository.getMirroredRepositories().isEmpty() ) | ||
| { | ||
| throw new NoRepositoryConnectorException( repository, "Blocked repository: " + repository ); |
There was a problem hiding this comment.
we should probably have some tests, because to me it is not clear where this exception is caught and logged. Does it prevent other remote repos from being tried or not?
There was a problem hiding this comment.
if you look from where this block was removed, it is in same try-catch where this method is invoked (and throws this exception). This move basically prevents any "remote access" to blocked repositories, not just for one case like originally. But yes, I agree, we do need test, I thought to reuse existing ones (are there any?)
There was a problem hiding this comment.
But if I have one blocked remote repo and one not-blocked one I expect the latter to be used instead (if possible). Resolving should only fail if the requested artifact/metadata could not be delivered from any non-blocked remote repo.
There was a problem hiding this comment.
Yes, as connector provider provides connector for one given remote repo (is param on method), so it will happily provide connector instance for other non-blocked remote repositories....
There was a problem hiding this comment.
Ok, sorry, now I see the related catch block in
and indeed that should work just as expected.
There was a problem hiding this comment.
Yes, in short: resolver will refuse to provide any connector for blocked RemoteRepository instances. Everywhere.
As blocked is really about block remote access. Locally cached things should not be affected, but current solution did not cover all execution paths.
https://issues.apache.org/jira/browse/MRESOLVER-305