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.
