答复: OS
The previously written project wants to run it on Windows 2019, so investigate whether Windows 2019 supports these modules. 差出人: Davi Baldin Tavares 送信日時: Thursday, April 18, 2019 11:17:11 AM 宛先: users@felix.apache.org CC: users-ow...@felix.apache.org 件名: Re: OS Are you facing some issue? My guess it they depends on jvm more than to de OS.. Davi > On 17 Apr 2019, at 23:36, "liname...@outlook.com" > wrote: > > > Hello, I am doing an investigation. > Does Windows Server 2019 support the following products: > > Felix Bundle Repository1.6.6 > Felix configAdmin 1.6.0 > Felix FileInstall 3.2.8 > Felix Framework 4.2.1 > Felix Framework(org.osgi/org.osgi.core) 5.0.0 > Felix GoGo Runtime 0.10.0 > Felix Metatype1.0.10 > Felix Webconsole Plugin 1.0.0 > Felix Webconsole Plugin Event 1.1.0 > Service OBR 1.0.2 > > Is the other version supported? > Can you tell me, thank you very much. > > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OS
Are you facing some issue? My guess it they depends on jvm more than to de OS.. Davi > On 17 Apr 2019, at 23:36, "liname...@outlook.com" > wrote: > > > Hello, I am doing an investigation. > Does Windows Server 2019 support the following products: > > Felix Bundle Repository1.6.6 > Felix configAdmin 1.6.0 > Felix FileInstall 3.2.8 > Felix Framework 4.2.1 > Felix Framework(org.osgi/org.osgi.core) 5.0.0 > Felix GoGo Runtime 0.10.0 > Felix Metatype1.0.10 > Felix Webconsole Plugin 1.0.0 > Felix Webconsole Plugin Event 1.1.0 > Service OBR 1.0.2 > > Is the other version supported? > Can you tell me, thank you very much. > > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
OS
Hello, I am doing an investigation. Does Windows Server 2019 support the following products: Felix Bundle Repository1.6.6 Felix configAdmin 1.6.0 Felix FileInstall 3.2.8 Felix Framework 4.2.1 Felix Framework(org.osgi/org.osgi.core) 5.0.0 Felix GoGo Runtime 0.10.0 Felix Metatype1.0.10 Felix Webconsole Plugin 1.0.0 Felix Webconsole Plugin Event 1.1.0 Service OBR 1.0.2 Is the other version supported? Can you tell me, thank you very much.
Anyone using felix on z/OS USS?
Hi, I'm wondering if anyone using felix on z/OS USS. The console seems not work under USS. See https://issues.apache.org/jira/browse/FELIX-5222. Best regards Kisho
Re: Shutdown deadlock on OS X while doing AWT stuff
Yeah, it worked. I had to write a dynamic proxy to access the API because Eclipse complains about access restrictions for com.apple.eawt but once I'd written the code, exported the package from my system bundle fragment and imported into the new bundle it all worked fine. On Tue, Mar 5, 2013 at 5:51 PM, Dan Gravell elstensoftw...@googlemail.comwrote: Thanks everyone. I was unaware of the Apple Application library and so I'll create a bundle for OS X which registers its own QuitHandler and see if that helps things. I'll pursue other suggestions afterwards. Dan On Tue, Mar 5, 2013 at 2:36 PM, Jan Willem Janssen janwillem.jans...@luminis.eu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/13 3:23 PM, Dan Gravell wrote: Well, I could be explicitly stopping the framework, or the stop could occur when the OS is shutdown and it *appears* this com.apple.eawt._AppEventHandler kicks in and calls System.exit... Does that count as an explicit stop? FWIW: The eawt application-quit hook calls System.exit(0) by default, see [1]. Either set another quit strategy or call QuitResponse#cancelQuit in your QuitHandler. Hope this helps, [1] http://developer.apple.com/library/mac/documentation/Java/Reference/JavaSE6_AppleExtensionsRef/api/com/apple/eawt/QuitStrategy.html - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNgL5AAoJEKF/mP2eHDc4EGsP/iWKEhx/EG9Gmu7iOO9XN05b prFlolILB+STYP3akDBIuaI973H6UFofqdlCAiBcrbJWV2doXYcXzEv7aBIzSCLI uZprA+z2dW9kaWp24QrOtNMH3bTR27a46/WSjiyAVEY3oYo+4GqKUwSzgTy4lFE0 P8eH1SzyFTZRwaa1engT8sieiEbgImR6o3GtFJlZqK9D0bBs28lF7U2kJFIvu+er JlerOPwLN4VKe2DZO2iA6gS7NatQTcjXL0tkwmYY890cJhW4/v9RU1VHZOstf2PA bWHN43dAE9J6r9MJY7fOdRx2uOYYM6rhlSZBqPIMMOInRcWHZ0SFuaqMpx9UzK/s ZY0A1GGkZ2o4aNCzyI91CM9xF9w3Q/q+TxH2SUP0xQyTJ3LOWf4GCmwXw5O8rd7H FAJK4ui6Pr98P2kmCWA/9wSrm5xVxuC3/pbzE5pYqT0wXvn00IIvlPF813fIszYC xpL/zsyLt+SPjV/N0HQ1JBVoDZC6u/sGwkbwMbsl2HC79C+hEt1ELBOE5+BHwGW0 dOAOn0b5Hkq3tCLzWIdwhuXHpn1fLNcTvoMQ1LbP9pHC0Nh6nz1GbclRTIu8jRMo zGGHJeltYPnGFLdAVUc10Mrq3O9abnWxDa1UB3KXLnr8GkzoGMVqS6/3142V/oTM 8m58tIyf47Z28IxreoGy =FS4a -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Shutdown deadlock on OS X while doing AWT stuff
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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Shutdown deadlock on OS X while doing AWT stuff
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-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
Re: Shutdown deadlock on OS X while doing AWT stuff
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 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
Re: Shutdown deadlock on OS X while doing AWT stuff
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
Re: Shutdown deadlock on OS X while doing AWT stuff
How are you launching the framework? I'm just running felix.jar. 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. Well, I could be explicitly stopping the framework, or the stop could occur when the OS is shutdown and it *appears* this com.apple.eawt._AppEventHandler kicks in and calls System.exit... Does that count as an explicit stop? Note that my reading of the stack trace may not be correct. After all, I would've thought someone had noticed this before. Dan
Re: Shutdown deadlock on OS X while doing AWT stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/13 3:23 PM, Dan Gravell wrote: Well, I could be explicitly stopping the framework, or the stop could occur when the OS is shutdown and it *appears* this com.apple.eawt._AppEventHandler kicks in and calls System.exit... Does that count as an explicit stop? FWIW: The eawt application-quit hook calls System.exit(0) by default, see [1]. Either set another quit strategy or call QuitResponse#cancelQuit in your QuitHandler. Hope this helps, [1] http://developer.apple.com/library/mac/documentation/Java/Reference/JavaSE6_AppleExtensionsRef/api/com/apple/eawt/QuitStrategy.html - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNgL5AAoJEKF/mP2eHDc4EGsP/iWKEhx/EG9Gmu7iOO9XN05b prFlolILB+STYP3akDBIuaI973H6UFofqdlCAiBcrbJWV2doXYcXzEv7aBIzSCLI uZprA+z2dW9kaWp24QrOtNMH3bTR27a46/WSjiyAVEY3oYo+4GqKUwSzgTy4lFE0 P8eH1SzyFTZRwaa1engT8sieiEbgImR6o3GtFJlZqK9D0bBs28lF7U2kJFIvu+er JlerOPwLN4VKe2DZO2iA6gS7NatQTcjXL0tkwmYY890cJhW4/v9RU1VHZOstf2PA bWHN43dAE9J6r9MJY7fOdRx2uOYYM6rhlSZBqPIMMOInRcWHZ0SFuaqMpx9UzK/s ZY0A1GGkZ2o4aNCzyI91CM9xF9w3Q/q+TxH2SUP0xQyTJ3LOWf4GCmwXw5O8rd7H FAJK4ui6Pr98P2kmCWA/9wSrm5xVxuC3/pbzE5pYqT0wXvn00IIvlPF813fIszYC xpL/zsyLt+SPjV/N0HQ1JBVoDZC6u/sGwkbwMbsl2HC79C+hEt1ELBOE5+BHwGW0 dOAOn0b5Hkq3tCLzWIdwhuXHpn1fLNcTvoMQ1LbP9pHC0Nh6nz1GbclRTIu8jRMo zGGHJeltYPnGFLdAVUc10Mrq3O9abnWxDa1UB3KXLnr8GkzoGMVqS6/3142V/oTM 8m58tIyf47Z28IxreoGy =FS4a -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Shutdown deadlock on OS X while doing AWT stuff
Hi,
On Tue, Mar 5, 2013 at 2:15 PM, Dan Gravell
elstensoftw...@googlemail.com wrote:
...Stopping the
bundles has the effect of calling:
@Deactivate def shutdown() {
awt.SystemTray.getSystemTray.getTrayIcons.foreach(systemTray.remove);
...
It's been a long time since I did any AWT...shouldn't that be called
with EventQueue.invokeAndWait(...) to avoid trouble with the AWT
events queue thread?
-Bertrand
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Shutdown deadlock on OS X while doing AWT stuff
Thanks everyone. I was unaware of the Apple Application library and so I'll create a bundle for OS X which registers its own QuitHandler and see if that helps things. I'll pursue other suggestions afterwards. Dan On Tue, Mar 5, 2013 at 2:36 PM, Jan Willem Janssen janwillem.jans...@luminis.eu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/13 3:23 PM, Dan Gravell wrote: Well, I could be explicitly stopping the framework, or the stop could occur when the OS is shutdown and it *appears* this com.apple.eawt._AppEventHandler kicks in and calls System.exit... Does that count as an explicit stop? FWIW: The eawt application-quit hook calls System.exit(0) by default, see [1]. Either set another quit strategy or call QuitResponse#cancelQuit in your QuitHandler. Hope this helps, [1] http://developer.apple.com/library/mac/documentation/Java/Reference/JavaSE6_AppleExtensionsRef/api/com/apple/eawt/QuitStrategy.html - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNgL5AAoJEKF/mP2eHDc4EGsP/iWKEhx/EG9Gmu7iOO9XN05b prFlolILB+STYP3akDBIuaI973H6UFofqdlCAiBcrbJWV2doXYcXzEv7aBIzSCLI uZprA+z2dW9kaWp24QrOtNMH3bTR27a46/WSjiyAVEY3oYo+4GqKUwSzgTy4lFE0 P8eH1SzyFTZRwaa1engT8sieiEbgImR6o3GtFJlZqK9D0bBs28lF7U2kJFIvu+er JlerOPwLN4VKe2DZO2iA6gS7NatQTcjXL0tkwmYY890cJhW4/v9RU1VHZOstf2PA bWHN43dAE9J6r9MJY7fOdRx2uOYYM6rhlSZBqPIMMOInRcWHZ0SFuaqMpx9UzK/s ZY0A1GGkZ2o4aNCzyI91CM9xF9w3Q/q+TxH2SUP0xQyTJ3LOWf4GCmwXw5O8rd7H FAJK4ui6Pr98P2kmCWA/9wSrm5xVxuC3/pbzE5pYqT0wXvn00IIvlPF813fIszYC xpL/zsyLt+SPjV/N0HQ1JBVoDZC6u/sGwkbwMbsl2HC79C+hEt1ELBOE5+BHwGW0 dOAOn0b5Hkq3tCLzWIdwhuXHpn1fLNcTvoMQ1LbP9pHC0Nh6nz1GbclRTIu8jRMo zGGHJeltYPnGFLdAVUc10Mrq3O9abnWxDa1UB3KXLnr8GkzoGMVqS6/3142V/oTM 8m58tIyf47Z28IxreoGy =FS4a -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Problems On OS X
Hi, Last night I downloaded the most recent version of Felix as a gzipped tarball and installed it under /usr/local/... After starting felix with java -jar .../bin/felix.jar I got the Felix version number and a row of equal signs but not the - prompt or any other prompt. I did wait for several minutes. I am running Snow Leopard 10.6.1 and if I remember correctly, Felix was at 2.1.x. Sorry, my laptop is at home and I am not sure about the exact version number. My Java is at 1.5.x. How should I go about debugging this problem? TIA, -- Johannes Obligatory current favourite quotes: I have more confidence in the methods of science, based on the amazing record of science and its ability over the centuries to answer unanswerable questions, than I do in the methods of faith (what are they?). -- David J. Gross Physics Nobel Laureate Atheism is a religion to the same extent that not collecting stamps is a hobby. -- seen on Slashdot.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Problems On OS X
I think Felix is meant to be started from the install root with the command java -jar bin/felix.jar. If you want a different location for the bundle cache you can use java -jar bin/felix.jar newpath or take a look at the config properties org.osgi.framework.storage, felix.cache.rootdir, etc. from here: http://felix.apache.org/site/apache-felix-framework-usage-documentation.html#ApacheFelixFrameworkUsageDocumentation-configuringframework Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Nov 9, 2009 at 9:54 AM, Johannes Ruscheinski rusch...@gmail.comwrote: Hi, Last night I downloaded the most recent version of Felix as a gzipped tarball and installed it under /usr/local/... After starting felix with java -jar .../bin/felix.jar I got the Felix version number and a row of equal signs but not the - prompt or any other prompt. I did wait for several minutes. I am running Snow Leopard 10.6.1 and if I remember correctly, Felix was at 2.1.x. Sorry, my laptop is at home and I am not sure about the exact version number. My Java is at 1.5.x. How should I go about debugging this problem? TIA, -- Johannes Obligatory current favourite quotes: I have more confidence in the methods of science, based on the amazing record of science and its ability over the centuries to answer unanswerable questions, than I do in the methods of faith (what are they?). -- David J. Gross Physics Nobel Laureate Atheism is a religion to the same extent that not collecting stamps is a hobby. -- seen on Slashdot.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Problems On OS X
Hi Chris, On Mon, Nov 9, 2009 at 11:29 AM, Chris Custine chris.cust...@gmail.com wrote: I think Felix is meant to be started from the install root with the command java -jar bin/felix.jar. If you want a different location for the bundle I started it with java -jar /usr/local/ForgotTheName/bin/felix.jar. Is that a problem? In other words, do I have to be in the parent directory of Felix' bin directory? cache you can use java -jar bin/felix.jar newpath or take a look at the config properties org.osgi.framework.storage, felix.cache.rootdir, etc. from here: http://felix.apache.org/site/apache-felix-framework-usage-documentation.html#ApacheFelixFrameworkUsageDocumentation-configuringframework Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, Nov 9, 2009 at 9:54 AM, Johannes Ruscheinski rusch...@gmail.comwrote: Hi, Last night I downloaded the most recent version of Felix as a gzipped tarball and installed it under /usr/local/... After starting felix with java -jar .../bin/felix.jar I got the Felix version number and a row of equal signs but not the - prompt or any other prompt. I did wait for several minutes. I am running Snow Leopard 10.6.1 and if I remember correctly, Felix was at 2.1.x. Sorry, my laptop is at home and I am not sure about the exact version number. My Java is at 1.5.x. How should I go about debugging this problem? TIA, -- Johannes Obligatory current favourite quotes: I have more confidence in the methods of science, based on the amazing record of science and its ability over the centuries to answer unanswerable questions, than I do in the methods of faith (what are they?). -- David J. Gross Physics Nobel Laureate Atheism is a religion to the same extent that not collecting stamps is a hobby. -- seen on Slashdot.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Johannes Obligatory current favourite quotes: I have more confidence in the methods of science, based on the amazing record of science and its ability over the centuries to answer unanswerable questions, than I do in the methods of faith (what are they?). -- David J. Gross Physics Nobel Laureate Atheism is a religion to the same extent that not collecting stamps is a hobby. -- seen on Slashdot.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Problems On OS X
On Mon, Nov 9, 2009 at 9:21 PM, Johannes Ruscheinski rusch...@gmail.com wrote: I started it with java -jar /usr/local/ForgotTheName/bin/felix.jar. Is that a problem? In other words, do I have to be in the parent directory of Felix' bin directory? You may try: java -Dfelix.auto.deploy.dir=/usr/local/ForgotTheName/bundle -jar /usr/local/ForgotTheName/bin/felix.jar If you have other problems, you may turn on debug with following options: -Dfelix.log.level=4 Those options are documented in Chris's link. -Guo - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Problems On OS X
On Mon, Nov 9, 2009 at 2:00 PM, Guo Du mrdu...@gmail.com wrote: On Mon, Nov 9, 2009 at 9:21 PM, Johannes Ruscheinski rusch...@gmail.com wrote: I started it with java -jar /usr/local/ForgotTheName/bin/felix.jar. Is that a problem? In other words, do I have to be in the parent directory of Felix' bin directory? You may try: java -Dfelix.auto.deploy.dir=/usr/local/ForgotTheName/bundle -jar /usr/local/ForgotTheName/bin/felix.jar That did it, thanks a lot! If you have other problems, you may turn on debug with following options: -Dfelix.log.level=4 Those options are documented in Chris's link. Ok, I'll have a look. -Guo - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org -- Johannes Obligatory current favourite quotes: I have more confidence in the methods of science, based on the amazing record of science and its ability over the centuries to answer unanswerable questions, than I do in the methods of faith (what are they?). -- David J. Gross Physics Nobel Laureate Atheism is a religion to the same extent that not collecting stamps is a hobby. -- seen on Slashdot.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
