Sorry, 'platform' is my code.
Here's the full listing for platform.shutdown:
public void shutdown() {
if(null!=main) main.shutdown();
if(lastContext!=null) {
try {
lastContext.getBundle(0).stop();
} catch (BundleException e) {
LOG.error("Failed to stop system bundle, attempting system.exit", e);
System.exit(0);
}
} else {
LOG.error("Failed to stop system bundle because had no BundleContext");
System.exit(0);
}
}
As far as I can see, "main.shutdown" is not causing any trouble, because if
@deactivate is being called on my Components,
lastContext.getBundle(0).stop() must've been called. main.shutdown()
performs some further shut down code, code that otherwise I guess could be
part of another @deactivate.
I don't receive any of the log messages.
I'm beginning to wonder if this is just a interoperability problem with
System.exit being called as a result of system shutdown.
Dan
On Tue, Mar 5, 2013 at 1:54 PM, Ferry Huberts <[email protected]> wrote:
>
>
> 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:
>> users-unsubscribe@felix.**apache.org<[email protected]>
>> For additional commands, e-mail: [email protected]
>>
>>
> --
> Ferry Huberts
>
