Bug 248828 - Can't share editor: Failed to execute item null
Summary: Can't share editor: Failed to execute item null
Status: RESOLVED DUPLICATE of bug 240926
Alias: None
Product: ECF
Classification: RT
Component: ecf.cola (show other bugs)
Version: 2.0.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: ecf.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-27 06:13 EDT by Jan Ploski CLA
Modified: 2008-09-28 01:24 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Ploski CLA 2008-09-27 06:13:51 EDT
Build ID: I20080617-2000

Steps To Reproduce (as far as can I recall):

1. Connect to XMPP server (OpenFire in this case)
2. Add a contact
3. Share a Java editor
4. After a bit of shared editing, close the editor on both sides of the session, discarding changes
5. Try opening the editor again - nothing happens in the UI. It doesn't allow sharing of another file either. However, exceptions are logged, see below.

More information:
In Error Log two entries "Failed to execute item null" are added upon executing the failing Share Editor With.. action. Detail:

org.eclipse.core.commands.ExecutionException: Editor is already sharing
at org.eclipse.ecf.internal.provisional.docshare.menu.DocShareRosterMenuHandler.execute(DocShareRosterMenuHandler.java:81)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at org.eclipse.ui.menus.CommandContributionItem.handleWidgetSelection(CommandContributionItem.java:619)
at org.eclipse.ui.menus.CommandContributionItem.access$10(CommandContributionItem.java:605)
at org.eclipse.ui.menus.CommandContributionItem$4.handleEvent(CommandContributionItem.java:595)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
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)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
Comment 1 Jan Ploski CLA 2008-09-27 06:22:33 EDT
I just wanted to add that I can reproduce this behavior easily. Step 2 (add contact) is not necessary to reproduce. I just share an editor, do some edits, close without saving on both sides (doesn't matter in what order), then reopen the editor on the initiator and try sharing it again - the exception always happens then.
Comment 2 Scott Lewis CLA 2008-09-27 11:32:27 EDT
I believe that this bug is likely a duplicate of bug #240926, which has been addressed for ECF 2.0.1 (Eclipse 3.4.1).

Could you perhaps try ECF 2.0.1 (installed via Ganymede 3.4.1 update site) in your environment, and if you cannot reproduce we'll resolve this as duplicate?

Comment 3 Jan Ploski CLA 2008-09-27 12:38:11 EDT
(In reply to comment #2)
> I believe that this bug is likely a duplicate of bug #240926, which has been
> addressed for ECF 2.0.1 (Eclipse 3.4.1).
> 
> Could you perhaps try ECF 2.0.1 (installed via Ganymede 3.4.1 update site) in
> your environment, and if you cannot reproduce we'll resolve this as duplicate?

I just checked - the problem does not occur in Ganymede 3.4.1/ECF 2.0.1.
Comment 4 Scott Lewis CLA 2008-09-28 01:24:42 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > I believe that this bug is likely a duplicate of bug #240926, which has been
> > addressed for ECF 2.0.1 (Eclipse 3.4.1).
> > 
> > Could you perhaps try ECF 2.0.1 (installed via Ganymede 3.4.1 update site) in
> > your environment, and if you cannot reproduce we'll resolve this as duplicate?
> 
> I just checked - the problem does not occur in Ganymede 3.4.1/ECF 2.0.1.
> 

Thank you for checking.  Resolving as duplicate of bug #240926.



*** This bug has been marked as a duplicate of bug 240926 ***