Odd. The check for nested resolves only happens in two places (when
performing a normal resolve or a resolve for a dynamic import). In both
cases, the global lock is acquired first and then the "resolving" flag
is checked/set and unset using a finally block.
So, it seems the only potential problem area could be if somehow the
global lock was acquired when it shouldn't have been. Looking at the
code, it appears to do the right thing, so I'm not really sure without
being able to reproduce.
-> richard
On 2/1/12 04:40 , Guillaume Nodet wrote:
I just came across the following exception:
ERROR: Bundle org.apache.felix.fileinstall [6] Error starting xxxxxx
(java.lang.IllegalStateException: Nested resolve operations not
allowed.)
java.lang.IllegalStateException: Nested resolve operations not allowed.
at
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:114)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3887)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1885)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1208)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:680)
Given the stack trace clearly show no reentrance, I wonder if there's
a timing / synchronization issue here.
FWIW, I was running under a profile, so very slow and that may be the
reason why those exceptions have been raised (I don't usually see them
under normal conditions).
Thoughts?
