On 3/5/13 09:02 , Dan Gravell wrote:
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.
How are you launching the framework? If you are using the standard Felix
launcher, it registers a VM shutdown hook to actually stop the framework
which can sometimes cause issues. Since you are explicitly stopping the
framework, you could disable the launcher's shutdown hook in
conf/config.properties...look in that file and you'll see how to disable it.
That may or may not help.
-> richard
Dan
On Tue, Mar 5, 2013 at 1:54 PM, Ferry Huberts <maili...@hupie.com> 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<users-unsubscr...@felix.apache.org>
For additional commands, e-mail: users-h...@felix.apache.org
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
