In my OSGi app (running on Felix 4.0.2) I use the Java SystemTray to add
items to the system tray. One of these items is a 'quit' item:
miQuit.addActionListener(new ActionListener() {
@Override
def actionPerformed(e:ActionEvent) {
platform.shutdown();
}
});
Then, PlatformImpl.shutdown does a:
lastContext.getBundle(0).stop();
Where lastContext is the BundleContext for the containing bundle. The
SystemTray code and PlatformImpl are in different bundles. Stopping the
bundles has the effect of calling:
@Deactivate def shutdown() {
awt.SystemTray.getSystemTray.getTrayIcons.foreach(systemTray.remove);
}
This is back on the SystemTray component (I'm using bnd style DS here).
I am seeing a deadlock occur, but fairly infrequently and only on OS X. I
managed to get a stack trace last time. Here are two suspicious looking
threads (I attached the entire thing):
"FelixStartLevel" daemon prio=5 tid=109c2d800 nid=0x10f371000 in
Object.wait() [10f36e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7eae23890> (a java.awt.EventQueue$1AWTInvocationLock)
at java.lang.Object.wait(Object.java:485)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1117)
- locked <7eae23890> (a java.awt.EventQueue$1AWTInvocationLock)
at java.awt.Window.doDispose(Window.java:1036)
at java.awt.Window.dispose(Window.java:974)
at apple.awt.CTrayIconPeer.disposeImpl(CTrayIconPeer.java:58)
at apple.awt.PeerImpl.dispose(PeerImpl.java:30)
at java.awt.TrayIcon.removeNotify(TrayIcon.java:701)
at java.awt.SystemTray.remove(SystemTray.java:273)
- locked <7ed5e5968> (a java.awt.SystemTray)
at
com.elsten.bliss.ui.systemtray.SystemTray$$anonfun$shutdown$1.apply(SystemTray.scala:149)
at
com.elsten.bliss.ui.systemtray.SystemTray$$anonfun$shutdown$1.apply(SystemTray.scala:149)
at
scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:34)
at scala.collection.mutable.ArrayOps.foreach(ArrayOps.scala:38)
at com.elsten.bliss.ui.systemtray.SystemTray.shutdown(SystemTray.scala:149)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
[...]
"AWT-EventQueue-0" prio=6 tid=105d82800 nid=0x11505f000 in Object.wait()
[11505d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <7ece2ed20> (a org.apache.felix.main.Main$1)
at java.lang.Thread.join(Thread.java:1210)
- locked <7ece2ed20> (a org.apache.felix.main.Main$1)
at java.lang.Thread.join(Thread.java:1263)
at
java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:79)
at
java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:24)
at java.lang.Shutdown.runHooks(Shutdown.java:79)
at java.lang.Shutdown.sequence(Shutdown.java:123)
at java.lang.Shutdown.exit(Shutdown.java:168)
- locked <7faf9e240> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(Runtime.java:90)
at java.lang.System.exit(System.java:921)
at com.apple.eawt._AppEventHandler.performQuit(_AppEventHandler.java:124)
- locked <7ed6a2420> (a com.apple.eawt._AppEventHandler)
at com.apple.eawt.QuitResponse.performQuit(QuitResponse.java:31)
at
com.apple.eawt._AppEventHandler$_QuitDispatcher.performDefaultAction(_AppEventHandler.java:382)
at
com.apple.eawt._AppEventHandler$_AppEventDispatcher$1.run(_AppEventHandler.java:487)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
[...]
Is there something I'm doing incorrectly? It looks like
"_AppEventHandler.performQuit" is calling System.exit... but won't this be
prone to deadlocks with OSGi?
It's possible in this case that I chose to shutdown my app and this is what
sent the event. If this is the case how can I work around this? I'm
guessing that the removal of SystemTray items can't be done in this case,
or has to be done in some managed thread context.
Just wondering if anyone else has seen this.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
