[
https://issues.apache.org/jira/browse/FELIX-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-2533.
----------------------------------
Reported as fixed.
> Cause of unsatisfied requirements is lost sometimes when a bundles exports is
> a candidate for its own imports
> -------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-2533
> URL: https://issues.apache.org/jira/browse/FELIX-2533
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Reporter: James Roper
>
> If a bundle imports its own exports, then if another import from that bundle
> fails to resolve, it is possible that that error message will be lost, and
> instead an error message saying that the import of its own export couldn't be
> resolved is thrown. The problem is in ResolverImpl, in the
> populateCandidates method:
> {code:java}
> // Get satisfying candidates and populate their candidates if
> necessary.
> Set<Capability> candidates = state.getCandidates(module, req,
> true);
> for (Iterator<Capability> itCandCap = candidates.iterator();
> itCandCap.hasNext(); )
> {
> Capability candCap = itCandCap.next();
> if (!candCap.getModule().isResolved())
> {
> try
> {
> populateCandidates(state, candCap.getModule(),
> candidateMap, resultCache);
> }
> catch (ResolveException ex)
> {
> // Remove the candidate since we weren't able to
> // populate its candidates.
> itCandCap.remove();
> }
> }
> }
> // If there are no candidates for the current requirement
> // and it is not optional, then create, cache, and throw
> // a resolve exception.
> if ((candidates.size() == 0) && !req.isOptional())
> {
> ResolveException ex =
> new ResolveException("Unable to resolve " + module
> + ": missing requirement " + req, module, req);
> resultCache.put(module, ex);
> m_logger.log(Logger.LOG_DEBUG, "No viable candidates", ex);
> throw ex;
> }
> {code}
> Let's say I have bundle A, with the following exports/imports:
> {noformat}
> Export-Package: com.foo
> Import-Package: com.foo,com.bar
> {noformat}
> If populateCandidates tries to find candidates for com.foo first, it will
> find bundle A as a candidate. Because its currently resolving bundle A, it
> will recursively call populateCandidates to try and finish resolving bundle
> A. This next iteration will attempt to find candidates for com.bar, if this
> fails, it will throw a ResolveException. This will then get caught by the
> first invocation of populateCandidates, which is currently trying to find
> candidates for com.foo, and ignored. The bundle A candidate for com.foo is
> removed from the candidates, which then results in an exception being thrown,
> saying bundle A can't find any requirements for com.foo, when the real reason
> is that it couldn't find any requirements for com.bar.
> This results in developers banging their head against a wall wondering what
> on earth they've done wrong for hours on end.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
