Bugzilla – Full Text Bug Listing
| Summary: | [target] java.lang.StackOverflowError during loading target platform definitions | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Raymond Feng <enjoyjava> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | caniszczyk, curtis.windatt.public, tjwatson |
| Version: | 3.5 | ||
| Target Milestone: | 3.5 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Raymond Feng
uses clauses makes me cry Tom This is probably a dupe of bug 216934 You can try to set '-Dosgi.resolver.usesMode=ignore' on startup of Eclipse or simply remove uses clauses from your manifests. I did see this kind of stack overflow when changing the target with the new p2 target provisioner, but as I've fixed bugs there I haven't seen it again. Will keep my eyes open. Could you attach your target with all content removed except for the bundle manifests? The zip file can be downloaded from: http://people.apache.org/~rfeng/tuscany/target.zip (35MB, still uploading...) After unzip it, I can load the bundles using: c:\...modules> java -jar osgi-3.4.0-v20080605-1900.jar -configuration ..\features\configuration -console Thanks, Raymond I have been working on a testcase to reproduce myself. I managed to reproduce it with fragments which introduce uses conflicts. It only reproduces when using the resolver in devmode (which is what PDE does). I will look at your manifests to see if you are running into the same issue I see. (In reply to comment #5) > The zip file can be downloaded from: > > http://people.apache.org/~rfeng/tuscany/target.zip (35MB, still uploading...) > > After unzip it, I can load the bundles using: > > c:\...modules> java -jar osgi-3.4.0-v20080605-1900.jar -configuration > ..\features\configuration -console > > Thanks, > Raymond > Thanks for the test case. Your scenario is the same as the one I found. Basically a fragment is contributing a constraint (Import-package) which is causing a uses conflict in the host. The issue is when in development mode we did not detach the fragment so the extra "bad" constraint was remaining on the host after we marked the fragment as unresolvable. Then when we try to reresolve we would find the "bad" constaint again on the host and go into endless reresolve recursion. I have release a fix and new testcases to test for this scenario. |