On 05/03/13 14:15, Dan Gravell wrote:
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:
Why do you delegate to 'platform'.
I think you can call bundleContext.getBundle(0).stop() right there.
See if that fixes your deadlock
Otherwise try removing the systray items before calling stop.
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]
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
