[JBoss JIRA] (JBIDE-15383) Server Launch Configuration loses Classpath User Entries
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15383?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15383:
-------------------------------------
As for the rest of the issue, regarding custom additions being removed, I'm not able to replicate it. This was most likely solved in some previous issue, though I can't see where.
> Server Launch Configuration loses Classpath User Entries
> --------------------------------------------------------
>
> Key: JBIDE-15383
> URL: https://issues.jboss.org/browse/JBIDE-15383
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.0.Final
> Environment: Windows 7 64-bit, Java7u25 64-bit, Eclipse Kepler, JBoss AS 7.1.1
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Fix For: 4.2.1.Final, 4.3.0.Alpha1
>
> Attachments: JBIDE_1.png, JBIDE_2.png, JBIDE_3.png
>
>
> Any additions to the Server Launch Configuration's Classpath "User Entries" are lost when the dialog is closed and reopened.
> This is likely related; there appears to be an issue where the initial values of "User Entries" are also incorrect (and are reverted from the "Restore Default Entries" value) when the dialog is reopened.
> Specifically, the "org.jboss.ide.eclipse.as.core.server.launch.runJarContainer/JBoss 7.1 Runtime Server" library to a single external "jboss-modules.jar".
> The attachments describe what happens:
> * The initial state when editing the Launch Configuration is in [^JBIDE_1.png].
> * When the "Restore Default Entries" button is clicked, the values are changed to what should be the default state ([^JBIDE_2.png]).
> * When the dialog is closed and reopened, it reverts back to the way it appeared in [^JBIDE_1.png].
> * Similarly if I manually add an external directory (or any other entry, for that matter), as appears in [^JBIDE_3.png], after closing and reopening the dialog, it reverts back to the [^JBIDE_1.png] state.
> I've tried simply clicking "OK" and also making sure I click "Apply" before clicking "OK", but that doesn't seem to have an effect.
> I've been able to replicate this on two separate (similarly configured) machines.
> This sounds very similar to JBIDE-786, but that's very old and marked as Resolved a long time ago, so I figured it'd be appropriate to file a new issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-15383) Server Launch Configuration loses Classpath User Entries
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15383?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-15383:
--------------------------------
Fix Version/s: 4.2.1.Final
4.3.0.Alpha1
(was: 4.2.x)
> Server Launch Configuration loses Classpath User Entries
> --------------------------------------------------------
>
> Key: JBIDE-15383
> URL: https://issues.jboss.org/browse/JBIDE-15383
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.0.Final
> Environment: Windows 7 64-bit, Java7u25 64-bit, Eclipse Kepler, JBoss AS 7.1.1
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Fix For: 4.2.1.Final, 4.3.0.Alpha1
>
> Attachments: JBIDE_1.png, JBIDE_2.png, JBIDE_3.png
>
>
> Any additions to the Server Launch Configuration's Classpath "User Entries" are lost when the dialog is closed and reopened.
> This is likely related; there appears to be an issue where the initial values of "User Entries" are also incorrect (and are reverted from the "Restore Default Entries" value) when the dialog is reopened.
> Specifically, the "org.jboss.ide.eclipse.as.core.server.launch.runJarContainer/JBoss 7.1 Runtime Server" library to a single external "jboss-modules.jar".
> The attachments describe what happens:
> * The initial state when editing the Launch Configuration is in [^JBIDE_1.png].
> * When the "Restore Default Entries" button is clicked, the values are changed to what should be the default state ([^JBIDE_2.png]).
> * When the dialog is closed and reopened, it reverts back to the way it appeared in [^JBIDE_1.png].
> * Similarly if I manually add an external directory (or any other entry, for that matter), as appears in [^JBIDE_3.png], after closing and reopening the dialog, it reverts back to the [^JBIDE_1.png] state.
> I've tried simply clicking "OK" and also making sure I click "Apply" before clicking "OK", but that doesn't seem to have an effect.
> I've been able to replicate this on two separate (similarly configured) machines.
> This sounds very similar to JBIDE-786, but that's very old and marked as Resolved a long time ago, so I figured it'd be appropriate to file a new issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-15383) Server Launch Configuration loses Classpath User Entries
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15383?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15383:
-------------------------------------
To clarify how the behavior is different, 4-6 versions would return a classpath container in these instances, which is unresolved during display in the classpath tab. For as4-6, it seems as if nothing has changed, since what's there originally is still there later. But for AS 7 / wf, we generally display the jboss-modules jar directly, so it appears jboss-modules.jar was replaced with a classpath container, which is understandably confusing (though it has no practical behavior difference).
> Server Launch Configuration loses Classpath User Entries
> --------------------------------------------------------
>
> Key: JBIDE-15383
> URL: https://issues.jboss.org/browse/JBIDE-15383
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.0.Final
> Environment: Windows 7 64-bit, Java7u25 64-bit, Eclipse Kepler, JBoss AS 7.1.1
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Fix For: 4.2.x
>
> Attachments: JBIDE_1.png, JBIDE_2.png, JBIDE_3.png
>
>
> Any additions to the Server Launch Configuration's Classpath "User Entries" are lost when the dialog is closed and reopened.
> This is likely related; there appears to be an issue where the initial values of "User Entries" are also incorrect (and are reverted from the "Restore Default Entries" value) when the dialog is reopened.
> Specifically, the "org.jboss.ide.eclipse.as.core.server.launch.runJarContainer/JBoss 7.1 Runtime Server" library to a single external "jboss-modules.jar".
> The attachments describe what happens:
> * The initial state when editing the Launch Configuration is in [^JBIDE_1.png].
> * When the "Restore Default Entries" button is clicked, the values are changed to what should be the default state ([^JBIDE_2.png]).
> * When the dialog is closed and reopened, it reverts back to the way it appeared in [^JBIDE_1.png].
> * Similarly if I manually add an external directory (or any other entry, for that matter), as appears in [^JBIDE_3.png], after closing and reopening the dialog, it reverts back to the [^JBIDE_1.png] state.
> I've tried simply clicking "OK" and also making sure I click "Apply" before clicking "OK", but that doesn't seem to have an effect.
> I've been able to replicate this on two separate (similarly configured) machines.
> This sounds very similar to JBIDE-786, but that's very old and marked as Resolved a long time ago, so I figured it'd be appropriate to file a new issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-15383) Server Launch Configuration loses Classpath User Entries
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15383?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-15383:
-------------------------------------
The behavior between 4.x-6.x and 7-wf is slightly different, so the default classpath provider needs to redirect to the proper launch configurator to unify the resolution under one api. https://github.com/jbosstools/jbosstools-server/pull/293
> Server Launch Configuration loses Classpath User Entries
> --------------------------------------------------------
>
> Key: JBIDE-15383
> URL: https://issues.jboss.org/browse/JBIDE-15383
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.1.0.Final
> Environment: Windows 7 64-bit, Java7u25 64-bit, Eclipse Kepler, JBoss AS 7.1.1
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Fix For: 4.2.x
>
> Attachments: JBIDE_1.png, JBIDE_2.png, JBIDE_3.png
>
>
> Any additions to the Server Launch Configuration's Classpath "User Entries" are lost when the dialog is closed and reopened.
> This is likely related; there appears to be an issue where the initial values of "User Entries" are also incorrect (and are reverted from the "Restore Default Entries" value) when the dialog is reopened.
> Specifically, the "org.jboss.ide.eclipse.as.core.server.launch.runJarContainer/JBoss 7.1 Runtime Server" library to a single external "jboss-modules.jar".
> The attachments describe what happens:
> * The initial state when editing the Launch Configuration is in [^JBIDE_1.png].
> * When the "Restore Default Entries" button is clicked, the values are changed to what should be the default state ([^JBIDE_2.png]).
> * When the dialog is closed and reopened, it reverts back to the way it appeared in [^JBIDE_1.png].
> * Similarly if I manually add an external directory (or any other entry, for that matter), as appears in [^JBIDE_3.png], after closing and reopening the dialog, it reverts back to the [^JBIDE_1.png] state.
> I've tried simply clicking "OK" and also making sure I click "Apply" before clicking "OK", but that doesn't seem to have an effect.
> I've been able to replicate this on two separate (similarly configured) machines.
> This sounds very similar to JBIDE-786, but that's very old and marked as Resolved a long time ago, so I figured it'd be appropriate to file a new issue.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-18572) NPE while calling a diff between 2 versions of a JS file
by Andrei Ivanov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18572?page=com.atlassian.jira.plugi... ]
Andrei Ivanov commented on JBIDE-18572:
---------------------------------------
Unfortunately I don't have an exact way to reproduce it, I've just tried again.
But usually it involves going to the synchronize view and checking each file.
I think most of the time it gets triggered by clicking a new file, but I've just tried and I couldn't trigger it :(
> NPE while calling a diff between 2 versions of a JS file
> --------------------------------------------------------
>
> Key: JBIDE-18572
> URL: https://issues.jboss.org/browse/JBIDE-18572
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: visual-page-editor-core
> Affects Versions: 4.2.0.CR1
> Reporter: Xavier Coulon
> Assignee: Konstantin Marmalyukov
> Priority: Blocker
> Fix For: 4.2.1.Final
>
>
> Not sure if the error is related {{summarry}}, but here's the stacktrace:
> I did compare my current JS file with the first version in my history, which was an empty file, then I called the diff with the next version and I got this error. I kept having this error when comparing the current version with any other version of the file (if that can help to reproduce/identify the problem)
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.vpe.preview.editor.VpvEditor.formRequestToServer(VpvEditor.java:572)
> at org.jboss.tools.vpe.preview.editor.VpvEditor.access$0(VpvEditor.java:551)
> at org.jboss.tools.vpe.preview.editor.VpvEditor$EditorListener.partInputChanged(VpvEditor.java:674)
> at org.eclipse.ui.internal.WorkbenchPage$28.run(WorkbenchPage.java:5151)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.WorkbenchPage.firePartInputChanged(WorkbenchPage.java:5148)
> at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart$4.propertyChanged(CompatibilityPart.java:369)
> at org.eclipse.ui.part.WorkbenchPart.firePropertyChange(WorkbenchPart.java:132)
> at org.eclipse.compare.internal.CompareEditor.doSetInput(CompareEditor.java:313)
> at org.eclipse.compare.internal.CompareEditor.setInput(CompareEditor.java:254)
> at org.eclipse.compare.internal.CompareUIPlugin$1.run(CompareUIPlugin.java:546)
> at org.eclipse.compare.internal.CompareUIPlugin.syncExec(CompareUIPlugin.java:1413)
> at org.eclipse.compare.internal.CompareUIPlugin.internalOpenEditor(CompareUIPlugin.java:567)
> at org.eclipse.compare.internal.CompareUIPlugin.openEditorInBackground(CompareUIPlugin.java:537)
> at org.eclipse.compare.internal.CompareUIPlugin.openCompareEditor(CompareUIPlugin.java:526)
> at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:199)
> at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:180)
> at org.eclipse.team.internal.ui.actions.CompareRevisionAction.openInCompare(CompareRevisionAction.java:139)
> at org.eclipse.team.internal.ui.actions.CompareRevisionAction.run(CompareRevisionAction.java:102)
> at org.eclipse.team.internal.ui.history.LocalHistoryPage$9.open(LocalHistoryPage.java:414)
> at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48)
> at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:853)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:178)
> at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:850)
> at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1142)
> at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1249)
> at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:278)
> at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:272)
> at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:313)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4188)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1467)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1490)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1475)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1279)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4031)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3658)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:484)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-16427) Set Wildfly 8 java web services runtime to JBossWS/CXF from JAXWS RI
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16427?page=com.atlassian.jira.plugi... ]
Brian Fitzpatrick updated JBIDE-16427:
--------------------------------------
Fix Version/s: 4.2.0.Final
(was: 4.1.x)
(was: 4.2.x)
> Set Wildfly 8 java web services runtime to JBossWS/CXF from JAXWS RI
> --------------------------------------------------------------------
>
> Key: JBIDE-16427
> URL: https://issues.jboss.org/browse/JBIDE-16427
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: webservices
> Affects Versions: 4.1.1.Final
> Reporter: Joseph Hwang
> Assignee: Brian Fitzpatrick
> Fix For: 4.2.0.Final
>
> Attachments: wss-mvn.zip, WSSHelloWorld.zip
>
>
> I implement Java Web Services with wildfly 8 and eclipse kepler jboss tools with the reference site https://docs.jboss.org/author/display/JBWS/WS-Security .
> The deployment and generated client codes works well. But the the problem is web services runtime is JAXWS RI, not JBossWS/CXF. The eclipse console show the following message,
>
> INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default taskextensions/wssecurity}HelloWorldService from WSDL: http://localhost:8080/WSSHelloWorld/HelloWorld?wsdl
>
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean class is involved in <WILDFLY_HOME>\modules\system\layers\base\org\apache\cxf\impl\main\cxf-rt-core-2.7.7.jar file of JAXWS RI.
> So the configuration of web services mentioned in above reference site are useless, does not work at all.
> But the same project works well with JBoss EAP 6.1.1 and eclipse kepler jboss tools.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-18696) Application wizard: Can not show quickstarts list
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18696?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-18696:
------------------------------------------
[~cathat] can you maybe try to install a fresh IDE/JBDS? The other think that we could change is you to access it via a different network, but I dont see how we could achieve this.
> Application wizard: Can not show quickstarts list
> -------------------------------------------------
>
> Key: JBIDE-18696
> URL: https://issues.jboss.org/browse/JBIDE-18696
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.Final
> Environment: Windows 8 + Eclipse Luna (4.4)
> Reporter: Chunyun Chen
> Attachments: quickstarts-listed-win8.png, Screenshot1.png, Screenshot3.png, trace_after_restart.log, trace_before_restart.log
>
>
> The quickstarts are unable to be shown, so any quickstarts can not be chosen to create.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-18697) Error deploying exploded war on windows; fs / copy error
by Cássio Mazzochi Molin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18697?page=com.atlassian.jira.plugi... ]
Cássio Mazzochi Molin edited comment on JBIDE-18697 at 10/27/14 7:40 AM:
-------------------------------------------------------------------------
[~rob.stryker], the error no longer occurred after changing the permissions.
So, I think it's a good idea updating the error message.
PS.: The latest JBoss Tools version is amazing! And I am really impressed with the quick responses I have on JBoss Developer.
was (Author: cassiomolin):
[~rob.stryker], the error no longer occurred after changing the permissions.
So, I think it's a good idea changing the error message.
PS.: The latest JBoss Tools version is amazing! And I am really impressed with the quick responses I have on JBoss Developer.
> Error deploying exploded war on windows; fs / copy error
> --------------------------------------------------------
>
> Key: JBIDE-18697
> URL: https://issues.jboss.org/browse/JBIDE-18697
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Final
> Reporter: Rob Stryker
> Fix For: 4.2.1.Final
>
>
> https://developer.jboss.org/message/907562
> A user has reported that on windows, deploying a simple exploded war has failed with a copy error. This should be investigated
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (JBIDE-18572) NPE while calling a diff between 2 versions of a JS file
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18572?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov commented on JBIDE-18572:
------------------------------------------------
{quote}Thus this is probably happening on systems where a browser is not available - like windows 64bit windows like Andrei.{quote}
But browser is available everywhere, it's not VPE. But maybe it was still not initialized. Anyway, look through the code/trace and found that this error happens in unuseful code. To be sure that removing this code will not do any harm I need detailed steps to reproduce. Xavier, Andrei, please help me with it.
> NPE while calling a diff between 2 versions of a JS file
> --------------------------------------------------------
>
> Key: JBIDE-18572
> URL: https://issues.jboss.org/browse/JBIDE-18572
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: visual-page-editor-core
> Affects Versions: 4.2.0.CR1
> Reporter: Xavier Coulon
> Assignee: Konstantin Marmalyukov
> Priority: Blocker
> Fix For: 4.2.1.Final
>
>
> Not sure if the error is related {{summarry}}, but here's the stacktrace:
> I did compare my current JS file with the first version in my history, which was an empty file, then I called the diff with the next version and I got this error. I kept having this error when comparing the current version with any other version of the file (if that can help to reproduce/identify the problem)
> {code}
> java.lang.NullPointerException
> at org.jboss.tools.vpe.preview.editor.VpvEditor.formRequestToServer(VpvEditor.java:572)
> at org.jboss.tools.vpe.preview.editor.VpvEditor.access$0(VpvEditor.java:551)
> at org.jboss.tools.vpe.preview.editor.VpvEditor$EditorListener.partInputChanged(VpvEditor.java:674)
> at org.eclipse.ui.internal.WorkbenchPage$28.run(WorkbenchPage.java:5151)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.WorkbenchPage.firePartInputChanged(WorkbenchPage.java:5148)
> at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart$4.propertyChanged(CompatibilityPart.java:369)
> at org.eclipse.ui.part.WorkbenchPart.firePropertyChange(WorkbenchPart.java:132)
> at org.eclipse.compare.internal.CompareEditor.doSetInput(CompareEditor.java:313)
> at org.eclipse.compare.internal.CompareEditor.setInput(CompareEditor.java:254)
> at org.eclipse.compare.internal.CompareUIPlugin$1.run(CompareUIPlugin.java:546)
> at org.eclipse.compare.internal.CompareUIPlugin.syncExec(CompareUIPlugin.java:1413)
> at org.eclipse.compare.internal.CompareUIPlugin.internalOpenEditor(CompareUIPlugin.java:567)
> at org.eclipse.compare.internal.CompareUIPlugin.openEditorInBackground(CompareUIPlugin.java:537)
> at org.eclipse.compare.internal.CompareUIPlugin.openCompareEditor(CompareUIPlugin.java:526)
> at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:199)
> at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:180)
> at org.eclipse.team.internal.ui.actions.CompareRevisionAction.openInCompare(CompareRevisionAction.java:139)
> at org.eclipse.team.internal.ui.actions.CompareRevisionAction.run(CompareRevisionAction.java:102)
> at org.eclipse.team.internal.ui.history.LocalHistoryPage$9.open(LocalHistoryPage.java:414)
> at org.eclipse.ui.OpenAndLinkWithEditorHelper$InternalListener.open(OpenAndLinkWithEditorHelper.java:48)
> at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:853)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:50)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:178)
> at org.eclipse.jface.viewers.StructuredViewer.fireOpen(StructuredViewer.java:850)
> at org.eclipse.jface.viewers.StructuredViewer.handleOpen(StructuredViewer.java:1142)
> at org.eclipse.jface.viewers.StructuredViewer$6.handleOpen(StructuredViewer.java:1249)
> at org.eclipse.jface.util.OpenStrategy.fireOpenEvent(OpenStrategy.java:278)
> at org.eclipse.jface.util.OpenStrategy.access$2(OpenStrategy.java:272)
> at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:313)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4188)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1467)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1490)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1475)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1279)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4031)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3658)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:484)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months