Community
Participate
Working Groups
This might to turn out to be one of those things I've been doing wrong all along, but I'm seeing a change in M3 that looks like somethings broken, so thought I'd report. This is on Linux (I'm using Mint 11 64 bit). Normally, I launch eclipse from a bash shell script that ends with ${ECLIPSEEXE} -showlocation ${LOCATIONNAME} -console -consolelog -debug -data ${DATAWORKSPACE} -vm ${DEV_JRE} -vmargs ${DEV_JRE_ARGS} where the variables are all what they sound like ... eclipseexe being absolute path name to 'eclipse' executable. (So, I'm assuming all this has nothing to with using bash script ... but similar would happen with just 'eclipse' executable. Running the script from command line works fine. Now, for the problem (change in behavior). I have some "desktop launchers" defined that run the script (and specifies location to run, and workspace, etc). In M2 (and recent I builds, these launched fine. With M3, these "desktop launchers" did not work any longer. I'd get a message to see workspace .log (I'll attach one) that had nothing too useful in it ... seemed to only contain errors that occurred while trying to shutdown the failed attempt to open. By "chance" I noticed if I changed the launcher to "run in terminal" then eclipse would start fine, just like it did before. Here's what my desktop launcher file looks like: $ cat wtpHead.desktop [Desktop Entry] Version=1.0 Type=Application Terminal=true Icon[en_US]=gnome-panel-launcher Name[en_US]=wtpHead Exec=/home/davidw/builds/scripts/runEclipse.sh /home/davidw/builds/eclipse-SDK-4.2M3-linux-gtk-x86_64 /home/davidw/builds/workspaces/wtpHead Name=wtpHead Icon=/home/davidw/builds/scripts/icons/icon.xpm Comment[en_US]=
Created attachment 206172 [details] log from failed attempt to launch M3 with script
Upon investigation, this seems related to me specifying "-console" as one of the options in my script. Here's two more, simpler "launch shortcuts" that show the failing case and success terminal case with -console. Without -console, they both work fine. $ cat eclipse.desktop [Desktop Entry] Version=1.0 Type=Application Terminal=false Icon[en_US]=gnome-panel-launcher Exec=/home/davidw/builds/eclipse-SDK-4.2M3-linux-gtk-x86_64/eclipse/eclipse -console Name[en_US]=eclipseApp Name=eclipseApp Icon=gnome-panel-launcher [22:44:21] davidw@davidw-asus:~/Desktop $ cat eclipse-1.desktop [Desktop Entry] Version=1.0 Type=Application Terminal=true Icon[en_US]=gnome-panel-launcher Exec=/home/davidw/builds/eclipse-SDK-4.2M3-linux-gtk-x86_64/eclipse/eclipse -console Name[en_US]=eclipseAppInTerminal Name=eclipseAppInTerminal Icon=gnome-panel-launcher
Created attachment 206174 [details] configuration log from failed attempt When launching just "eclipse -console" the error is logged in the "configuration log" instead of "workspace log" but says about the same vague thing (to my untrained eye).
So ... its certainly understandable that "things wouldn't work right" if I said -console and yet there is no console for it to use. Apparently in past, the -console was ignored if there was no console ... don't know if on purpose or not :) ... and now it is not. Note: having (just) -consolelog on the command line still works as before ... that is if no "terminal" is available it is just ignored. So ... you can decide if this is a) too fringe of a "user error" to worry about b) improve the error handling so a user is at least told they said "-console" but there is no console to use, or c) go back to ignoring it (if that is even possible). I'd recommend the latter case ... but, I do not feel too strongly about it now that I know what it is. (And, btw, do not know if this is specific to linux, or not).
(In reply to comment #4) > So ... its certainly understandable that "things wouldn't work right" if I said > -console and yet there is no console for it to use. > > Apparently in past, the -console was ignored if there was no console ... don't > know if on purpose or not :) ... and now it is not. Note: having (just) > -consolelog on the command line still works as before ... that is if no > "terminal" is available it is just ignored. > > So ... you can decide if this is a) too fringe of a "user error" to worry about > b) improve the error handling so a user is at least told they said "-console" > but there is no console to use, or c) go back to ignoring it (if that is even > possible). > > I'd recommend the latter case ... but, I do not feel too strongly about it now > that I know what it is. (And, btw, do not know if this is specific to linux, or > not). The logic for handling the console is exactly this - if the -console option is specified but the console is not available, it logs an error, but should still launch the framework. I checked the code to be sure and it seems so. Tom, what do you think? Am I missing something?
Created attachment 206211 [details] Possible fix (In reply to comment #5) > > The logic for handling the console is exactly this - if the -console option is > specified but the console is not available, it logs an error, but should still > launch the framework. I checked the code to be sure and it seems so. > > Tom, what do you think? Am I missing something? I think you can duplicate this issue if you issue the "disconnect" command from the console running on System in/out. This causes the framework to shutdown once the shell is done with the gosh loop. I think the issue is the gogo console, when running on System.in/out, is not configured with --noshutdown. This causes org.apache.felix.gogo.shell.Shell.gosh() method to call context.getBundle(0).stop() if it cannot successfully connect to System.in/out. Here is a patch that makes sure --noshutdown is used in this case. Right now I have to set these during framework launch. Lazar, is there a better way to configure the session for standard in/out? Right now the session seems to be created by the shell automatically. Perhaps we should be creating this session ourselves so we can set what ever options we want from the equinox.console bundle instead of setting them at framework launch?
I should have mentioned that you can add this to your config.ini to work around this issue for now also: gosh.args=--noshutdown
(In reply to comment #6) > Created attachment 206211 [details] > Possible fix > > (In reply to comment #5) > > > > The logic for handling the console is exactly this - if the -console option is > > specified but the console is not available, it logs an error, but should still > > launch the framework. I checked the code to be sure and it seems so. > > > > Tom, what do you think? Am I missing something? > I think you can duplicate this issue if you issue the "disconnect" command from > the console running on System in/out. This causes the framework to shutdown > once the shell is done with the gosh loop. > > I think the issue is the gogo console, when running on System.in/out, is not > configured with --noshutdown. This causes > org.apache.felix.gogo.shell.Shell.gosh() method to call > context.getBundle(0).stop() if it cannot successfully connect to System.in/out. > > Here is a patch that makes sure --noshutdown is used in this case. Right now I > have to set these during framework launch. Lazar, is there a better way to > configure the session for standard in/out? Right now the session seems to be > created by the shell automatically. Perhaps we should be creating this session > ourselves so we can set what ever options we want from the equinox.console > bundle instead of setting them at framework launch? Unfortunately we cannot run away from the automatic creation of this session - it is always created by the gogo shell bundle if the --noshutdown option is not specified. Probably we could always specify this option so that the session does not get created. And if we really need a session on standard in/out, we could create it manually. But I have to check exactly how this could be technically achieved.
(In reply to comment #8) > Unfortunately we cannot run away from the automatic creation of this session - > it is always created by the gogo shell bundle if the --noshutdown option is not > specified. > Did you mean the --nointeractive option? I do set that option if no -console option was used or -console <port> option was used. This does prevent the gogo shell from starting on System in/out. > Probably we could always specify this option so that the session does not get > created. And if we really need a session on standard in/out, we could create it > manually. But I have to check exactly how this could be technically achieved. Right, this is what I was suggesting that could be done by the equinox.console bundle.
I released the current patch in commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ce9ce834452337419becbdc1f895b70a34ea2c5c Leaving bug open for possible improvements to how the interactive console session is opened with System in/out. David could you please test with the next I-Build in your environment?
(In reply to comment #9) > (In reply to comment #8) > > Unfortunately we cannot run away from the automatic creation of this session - > > it is always created by the gogo shell bundle if the --noshutdown option is not > > specified. > > > > Did you mean the --nointeractive option? I do set that option if no -console > option was used or -console <port> option was used. This does prevent the gogo > shell from starting on System in/out. > Yes, I meant exactly this option, just made mistake with the name.
(In reply to comment #10) > ... David could you please test with the > next I-Build in your environment? I tested with I20111101-0800 and all seemed fixed ... using a short cut without 'terminal' but still specifying -console, the IDE (once again) opened up fine; there were no messages in workspace or configuration logs. And, to make sure normal case still worked, I used short cut _with_ terminal, and -console, and terminal still opened, I could interact with OSGi there, all like normal.
(In reply to comment #4) > (And, btw, do not know if this is specific to linux, or not). It is not linux specific. I reproduced the bug on Mac. (In reply to comment #12) > > I tested with I20111101-0800 and all seemed fixed ... Thanks David! (In reply to comment #8) > > Probably we could always specify this option so that the session does not get > created. And if we really need a session on standard in/out, we could create it > manually. But I have to check exactly how this could be technically achieved. I opened bug 362659 to look into this improvement. Moving to Framework since that is where the fix for this issue got released. Marking as fixed.
