[jira] Closed: (FELIX-2533) Cause of unsatisfied requirements is lost sometimes when a bundles exports is a candidate for its own imports

["Richard S. Hall (JIRA)" <ji...@apache.org>]

     [ 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.