[
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689719#action_12689719
]
Richard S. Hall commented on FELIX-977:
---------------------------------------
Thanks for the patch. I looked it over. Generally speaking, I think your
optimizations make sense, but there is one change that introduces a bug.
When a bundle cannot be resolved, you no longer remove it from m_resolvedSet.
This set serves two purposes:
1. It is used for cycle detection.
2. It is the set of resolved bundles.
As you can see, by not removing it, you are saying it is resolved. This is
problematic when we searchResolvingResources() since it returns bundles as
resolved which were not.
Perhaps we need to break the set into two, one for cycle detection and one for
resolved bundles. I can make this change to your patch next week, but if you
want to have a go at it, feel free. Thanks.
> Bundle resolving runs extreme long
> ----------------------------------
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
> Reporter: Kristian Koehler
> Attachments: bundlerepo-patch-2009_03_26.txt, myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved
> dependency. In this file the resource with the name
> "org.springframework.core" has a requirement for the
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---------------------------
> (&(package=org.springframework.context)(version>=2.5.0))
> Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
> (&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
> Spring Context
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Beans
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when
> checking for existing information in the current list before added it
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a
> workaround for the problem of 'double resolving' (I also tried with a larger
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new
> ones...
> Thanks
> Kristian
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
