[
https://issues.apache.org/jira/browse/IVY-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310384#comment-17310384
]
Jaikiran Pai commented on IVY-1618:
-----------------------------------
The setDictatorResolver on ResolveEngine shouldn't be changing the resolver on
the Ivy settings. This has now been fixed and will be available in the next
release. Thank you for reporting this issue.
> ResolveEngine resets dictator resolver to null in the global configuration
> --------------------------------------------------------------------------
>
> Key: IVY-1618
> URL: https://issues.apache.org/jira/browse/IVY-1618
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.5.0
> Environment: Windows 10, Java 8, Ivy 2.5.0.
> Reporter: Sergei Zhirikov
> Assignee: Jaikiran Pai
> Priority: Minor
>
> ResolveEngine does not initialize its dictatorResover field in the
> constructor. As the result, when
> {code:java}
> public ResolveReport resolve(ModuleDescriptor md, ResolveOptions
> options){code}
> is called, the {{oldDictator}} local variable will be set to null in the
> beginning of the method. Then, in the end of the same method, inside the
> {{finally}} block, {{setDictatorResolver(null)}} will be called, which will
> not only set the private field in the ResolveEngine itself, but will also
> reset the dictator resolver in the global configuration. Why would it do
> that???
> The problem manifests itself when an {{Ivy}} instance is configured (using
> Java API) with only a dictator resolver, it will be able to handle a single
> call to {{resolve(...)}} successfully, and all subsequent calls will fail
> because of "no resolver available" (because the one that is supposed to be
> available, has been reset by the ResolveEngine, as described above).
> I have to admit that I am not very familiar with Ivy internals, but I find it
> extremely puzzling that an object that is a part of the internal
> implementation would change the global configuration at will.
> Looking at the implementation of {{Ivy}} and {{IvyContext}} classes, I get
> the impression that an {{Ivy}} instance is supposed to be thread-safe, in the
> sense that it should allow to call {{resolve(...)}} on the same instance from
> multiple threads safely. Am I mistaken? If there is supposed to be any thread
> safety, it is broken by the peculiar behavior of ResolveEngine with respect
> to setting the dictator resolver.
> In any case, I think it would be really helpful to explicitly mention thread
> safety (or lack thereof) in the Javadoc page of the main {{Ivy}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
