[
https://issues.apache.org/jira/browse/FELIX-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-1816.
-------------------------------
Resolution: Fixed
Fix Version/s: felix-2.2.0
Ok, well, the problem is in this case that the system bundle is still in the
STARTING state when it's stop method is called. That get us into the deadlock.
Now, a proper solution would probably include a timeout mechanism but for now i
just resolved the issue by having the framework throw an exception as a result
of the stop call (this is allowed by the spec and would happen with a timeout
too - eventually). Downside for you is that you don't get what you want (i.e.,
the framework shutdown) but an exception inside your Activator.start. Again,
what you would have to do is to at least wait for the framework to be in the
ACTIVE state before calling the stop method (you can check the state and if its
not ACTIVE then register a framework listener and wait for that event).
However, as a side effect this makes it possible again to call System.exit
inside an activator.start method while the framework is still in the STARTING
state. See FELIX-1812 for more on that.
> deadlock on SystemBundle.stop()
> -------------------------------
>
> Key: FELIX-1816
> URL: https://issues.apache.org/jira/browse/FELIX-1816
> Project: Felix
> Issue Type: Bug
> Affects Versions: felix-2.0.1
> Reporter: Dennis Geurts
> Assignee: Karl Pauls
> Fix For: felix-2.2.0
>
> Attachments: Activator.java, felix-framework-2.0.1.tar.gz,
> trace-nohook.log, trace.log
>
>
> When one calls SystemBundle.stop within BundleActivator.start(BundleContext)
> a deadlock occurs.
> I will attach a stacktrace.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
