Bugzilla – Full Text Bug Listing
| Summary: | attempt to bring up context menu on Dock icon locked up machine | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Patrick Mueller <pmuellr> |
| Component: | Client | Assignee: | Andrew Niefer <aniefer> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | aniefer, bokowski, bruce.mitchener, john.arthorne, skovatch, tjwatson |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Patrick Mueller
Wow, I thought Macs weren't supposed to fail like that ;) I haven't seen any problems killing the server on windows or Linux. Although I usually shut it down by invoking "close" from the OSGi console, I also often just kill the process. Tom, you seen anything like this? The Orion server is a pretty basic OSGi application that finishes asynchronously (essentially it has no "main" thread). The only bug I can find that is possibly related is bug 322342. This could also be related to orion being headless. There is no SWT and nobody is running an event loop. Hasn't happened to me yet (10.6.6) - but I do have to "Force Quit" since the app shows up on the dock but doesn't spin the event loop and thus doesn't have a proper menu. We're using the Equinox launcher but the app doesn't contain SWT at all. Scott, do you have any idea? I've had lots of crazy things happen with Eclipse mac apps when SWT isn't set up "just so". For some definition of "just so". If you implemented bug 336094, then some of this craziness goes away - once you figure out the "just so" bits. Or just ship as a .jar to be run from the command-line. Do I need to mention that I'm hesitant to ever run Orion again? On a Mac anyway. Is there actually a command-line invocation I could run today, using the existing drop? Just to clear up some of my Mac naivety, how do command line applications normally behave on the Mac? Do they normally show up in the dock? How are they typically closed? Can you launch Orion server from the command line and enable the OSGi console to manage the application: ./eclipse -console & (In reply to comment #5) > Just to clear up some of my Mac naivety, how do command line applications > normally behave on the Mac? Do they normally show up in the dock? How are they > typically closed? Can you launch Orion server from the command line and enable > the OSGi console to manage the application: > > ./eclipse -console & Yes, this should work correctly. I've done this in the past to debug startup/plugin loading issues. A command-line app will not show up in the Dock unless the application calls TransformProcessType() or loads AppKit (which does it implicitly) I'll try the Mac build shortly. My first guess is that the Info.plist needs something like 'LSBackgroundOnly' to indicate that it has no UI. See http://developer.apple.com/library/ios/#documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html%23//apple_ref/doc/uid/TP40009250-SW1 Let me answer some of these questions more specifically: > Just to clear up some of my Mac naivety, how do command line applications > normally behave on the Mac? Do they normally show up in the dock? No, only applications that present a UI should show up in the dock. The dock is not the same thing as a process manager. > How are they typically closed? There are a couple of ways. ctrl-C from the Terminal window that started it will work. You can also find it with /Applications/Utilities/Activity Monitor.app and kill it that way. > Can you launch Orion server from the command line and enable the OSGi console to manage the application: > > ./eclipse -console & You can launch it this way, but then all of your output goes to the console (/Applications/Utilities/Console.app) and you can't use the osgi prompt. If you run it without the '&' the output goes to the terminal window and you can still work with the console. Okay, I now have a better idea of what's going on here. Since the Orion application is headless we should prevent it from appearing in the dock. To do that, set the '-nosplash' option in the eclipse.ini file and then set 'LSBackgroundOnly' to 1 in the Info.plist file. The only problem with doing it that way is that to stop the server you need to run Activity Monitor or kill it from a Terminal window, and then you need to find the pid so you stop the right process. If you want the double-clickable application bundle Patrick's suggestion of a having a self-contained browser or displaying a console/dashboard UI to tell you what's going on is a good one. I think we should remove the calls to TransformProcessType and SetFrontProcess in the launcher. As long as the application bundle has a properly configured Info.plist the application will be started as a foreground application by default. In the normal case of the SWT starting up and dispatching events, the launcher doesn't need to do anything up front to force it. This will allow the launcher to support the standard Info.plist options without any extra work on our part. Moving to Andrew, who surely understood everything you said much better than I. It's not clear to me if this is a general launcher change or just a change to the Orion launcher. Until we have an SWT console as Pat suggests, it is a headless app and should behave like one on Mac. (In reply to comment #9) > Moving to Andrew, who surely understood everything you said much better than I. > It's not clear to me if this is a general launcher change or just a change to > the Orion launcher. Until we have an SWT console as Pat suggests, it is "a headless app and should behave like one on Mac A headless app on the mac, to me, means shipping a jar. That I can run with java -jar fooblatz.jar arg1 arg2 ... If you can't/don't want to ship it as a single .jar file (understandable), then a shell script which invokes java is fine. I don't feel comfortable running binaries like "eclipse" from the command-line (or putting in a crontab, etc). A horribly complicated script / set of scripts (think tomcat) would be preferable to a binary. The bar is pretty low there. (In reply to comment #10) > I don't feel comfortable running binaries like "eclipse" from the command-line > (or putting in a crontab, etc). A horribly complicated script / set of scripts > (think tomcat) would be preferable to a binary. The bar is pretty low there. Well that's definitely an interesting option, because other than the native launcher, Orion is entirely platform-independent (there are some optional natives for file system stuff but they can be omitted). And all our launcher does is find a Java VM and invoke a Java application. Given the varieties of exotic server hardware out there, having a purely platform-independent download would be handy. (In reply to comment #9) > It's not clear to me if this is a general launcher change or just a change to > the Orion launcher. There is no "Orion launcher", this is just the regular eclipse launcher. I can add '-nosplash' and set 'LSBackgroundOnly'. Setting "-nosplash" will avoid the call to TransformProcessType/SetFrontProcess. Looking at the launcher code, Mac appears to be different from all the other platform, on Mac you must set -nosplash to avoid this kind of initialization, all other platforms require -showsplash to make it happen. Any other changes to TransformProcessType/SetFrontProcess affects the launcher itself for all Eclipse, that kind of change would need to be raised over in Equinox/Launcher (ignoring the fact that I'm the one who will handle it over there :) ) (In reply to comment #10) > A headless app on the mac, to me, means shipping a jar. That I can run with > > java -jar fooblatz.jar arg1 arg2 ... > I don't feel comfortable running binaries like "eclipse" from the command-line > (or putting in a crontab, etc). A horribly complicated script / set of scripts > (think tomcat) would be preferable to a binary. The bar is pretty low there. If you don't like the native binary, then you can start things with: java <vm-args> -jar plugins/org.eclipse.equinox.launcher_1.2.0.v20110124-0830.jar <program-args> look in the eclipse.ini file to see the vm args we use. There is nothing specific to Orion here, all of this is the same launcher that starts 99% of the Eclipse based software out there. It's been around for years and ships on 22 different os/ws/arch configurations A "horribly complicated script / set of scripts" would be the antithesis to what we want here. I mention "a horribly complicated script" only as being preferable over a binary. Obviously I'd prefer a "super simple one line script". Could you supply directions - or a link to generic directions that probably already exist - to the invocation you just described, in a FAQ entry and whatever sort of README that you ship? I think that's all you need to do right now. I've added the -nosplash option, still need to figure out the best way to modify the info.plist since that file is generated automatically by pde.build. For the launcher, there is a wiki page http://wiki.eclipse.org/Equinox_Launcher, but it mostly covers using the binary. There is a category http://wiki.eclipse.org/Category:Launcher containing a few "Starting Eclipse..." pages that were written by others. N201102041215 works for me on the Mac - no dock icon anymore. You can double-click the .app to launch, but I would recommend starting it from the command line (./eclipse.app/Contents/MacOS/eclipse) since that will give you an easy way to stop the server. For orderly shutdown, you would enter "close" in the OSGi console. Marking as fixed *** Bug 334100 has been marked as a duplicate of this bug. *** |