[JBoss JIRA] (JBIDE-23660) CDK Server adapter should have an option to configure stop command
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23660?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23660:
--------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.4.Final)
> CDK Server adapter should have an option to configure stop command
> ------------------------------------------------------------------
>
> Key: JBIDE-23660
> URL: https://issues.jboss.org/browse/JBIDE-23660
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: cdk
> Affects Versions: 4.4.2.Final
> Reporter: Ricardo Martinelli Oliveira
> Assignee: Rob Stryker
> Fix For: 4.5.0.AM1
>
>
> CDK Server adapter lets configure the vagrant startup options. There should have an option to do the same in the stop.
> Why?
> It seems that CDK Server adapter uses _vagrant destroy_ to stop CDK, but using that option has its drawbacks, like for example:
> * If I'm stopping it to save resources, then I'm loosing all my job in it.
> * All images already pulled will be lost, so I cannot work offline
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JBIDE-23869) ClassCastException with Jolokia connection
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23869?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-23869:
-------------------------------------
[~aurelien.pupier] I think I need a more clear picture of what exactly you would like to see here.
> ClassCastException with Jolokia connection
> ------------------------------------------
>
> Key: JBIDE-23869
> URL: https://issues.jboss.org/browse/JBIDE-23869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx, openshift
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Labels: jmx, jolokia, openshift
> Fix For: 4.5.0.AM1
>
> Attachments: failure.png, image-2017-02-06-13-54-27-708.png
>
>
> !image-2017-02-06-13-54-27-708.png|thumbnail!
> {noformat}
> !ENTRY org.eclipse.core.jobs 4 2 2017-02-06 13:52:39.767
> !MESSAGE An internal error occurred during: "Connect Job".
> !STACK 0
> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long
> at org.jolokia.client.request.ValidatingResponseExtractor.extract(ValidatingResponseExtractor.java:58)
> at org.jolokia.client.J4pClient.execute(J4pClient.java:195)
> at org.jolokia.client.J4pClient.execute(J4pClient.java:168)
> at org.jolokia.client.J4pClient.execute(J4pClient.java:117)
> at org.jboss.tools.jmx.jolokia.JolokiaConnectionWrapper.verifyServerReachable(JolokiaConnectionWrapper.java:315)
> at org.jboss.tools.jmx.jolokia.JolokiaConnectionWrapper.connect(JolokiaConnectionWrapper.java:111)
> at org.jboss.tools.jmx.core.ConnectJob.run(ConnectJob.java:29)
> at org.jboss.tools.jmx.ui.internal.actions.DoubleClickAction$1.run(DoubleClickAction.java:71)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JBIDE-23869) ClassCastException with Jolokia connection
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23869?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-23869:
--------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.4.Final)
> ClassCastException with Jolokia connection
> ------------------------------------------
>
> Key: JBIDE-23869
> URL: https://issues.jboss.org/browse/JBIDE-23869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx, openshift
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Labels: jmx, jolokia, openshift
> Fix For: 4.5.0.AM1
>
> Attachments: failure.png, image-2017-02-06-13-54-27-708.png
>
>
> !image-2017-02-06-13-54-27-708.png|thumbnail!
> {noformat}
> !ENTRY org.eclipse.core.jobs 4 2 2017-02-06 13:52:39.767
> !MESSAGE An internal error occurred during: "Connect Job".
> !STACK 0
> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long
> at org.jolokia.client.request.ValidatingResponseExtractor.extract(ValidatingResponseExtractor.java:58)
> at org.jolokia.client.J4pClient.execute(J4pClient.java:195)
> at org.jolokia.client.J4pClient.execute(J4pClient.java:168)
> at org.jolokia.client.J4pClient.execute(J4pClient.java:117)
> at org.jboss.tools.jmx.jolokia.JolokiaConnectionWrapper.verifyServerReachable(JolokiaConnectionWrapper.java:315)
> at org.jboss.tools.jmx.jolokia.JolokiaConnectionWrapper.connect(JolokiaConnectionWrapper.java:111)
> at org.jboss.tools.jmx.core.ConnectJob.run(ConnectJob.java:29)
> at org.jboss.tools.jmx.ui.internal.actions.DoubleClickAction$1.run(DoubleClickAction.java:71)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JBIDE-24084) To succesfully start CDKv3 Server adapter with hyperV provider, IDE must be started with admin rights
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24084?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-24084.
---------------------------------
Resolution: Done
The upstream issue seems to have been solved today... so ... um... let's see if it works?
> To succesfully start CDKv3 Server adapter with hyperV provider, IDE must be started with admin rights
> -----------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24084
> URL: https://issues.jboss.org/browse/JBIDE-24084
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.4.AM1
> Environment: Windows 10 Pro, x86_64
> HyperV allowed
> Reporter: Ondrej Dockal
> Priority: Blocker
> Fix For: 4.4.4.Final, 4.5.0.AM1
>
>
> One must run devstudio with admin rights to be able to start CDKv3 server adapter with hyperV vm-provider. Also, setup-cdk command must be run in cli before server adapter is started in IDE (admin rights are not required).
> I am not sure, if those issues are bugs or more features requests/enhancements, but we should definitely do something about it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JBIDE-24084) To succesfully start CDKv3 Server adapter with hyperV provider, IDE must be started with admin rights
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24084?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-24084:
--------------------------------
Fix Version/s: 4.5.0.AM1
> To succesfully start CDKv3 Server adapter with hyperV provider, IDE must be started with admin rights
> -----------------------------------------------------------------------------------------------------
>
> Key: JBIDE-24084
> URL: https://issues.jboss.org/browse/JBIDE-24084
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.4.AM1
> Environment: Windows 10 Pro, x86_64
> HyperV allowed
> Reporter: Ondrej Dockal
> Priority: Blocker
> Fix For: 4.4.4.Final, 4.5.0.AM1
>
>
> One must run devstudio with admin rights to be able to start CDKv3 server adapter with hyperV vm-provider. Also, setup-cdk command must be run in cli before server adapter is started in IDE (admin rights are not required).
> I am not sure, if those issues are bugs or more features requests/enhancements, but we should definitely do something about it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JBIDE-24186) Eclipse workspace deadlocking during refresh/rebuild
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24186?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-24186:
--------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.4.Final)
> Eclipse workspace deadlocking during refresh/rebuild
> ----------------------------------------------------
>
> Key: JBIDE-24186
> URL: https://issues.jboss.org/browse/JBIDE-24186
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven, server
> Affects Versions: 4.4.3.Final
> Reporter: Beirti O'Nunain
> Assignee: Rob Stryker
> Fix For: 4.5.0.AM1
>
>
> - Windows 7
> - Eclipse Neon.2 (4.6.2)
> - Developer Studio 10.3.0
> After a workspace SVN update, the rebuild in Eclipse hangs (Eclipse remains responsive for a short time) with the following jobs in the progress pane:
> + "Refreshing '/my-non-j2ee-webproject/target/m2e-wtp/web-resources'"
> + Updating Maven Project (Waiting)
> + Updating Maven Project (Waiting)
> + Updating Maven Project (Waiting)
> + Updating Maven Project (Waiting)
> ....
> The project referenced above is a simple web project with no J2EE or JBoss components, nor is it referenced by any servers in the workspace.
> Profiling with yourkit detects a deadlock in the following thread:
> Worker-33 <--- Frozen for at least 8m 27s
> org.eclipse.wst.server.core.internal.Server.getModules() Server.java:2526
> org.eclipse.wst.server.core.internal.Server.visit(IModuleVisitor, IProgressMonitor) Server.java:3035
> org.eclipse.wst.server.core.internal.Server$ResourceChangeJob.run(IProgressMonitor) Server.java:228
> org.eclipse.core.internal.jobs.Worker.run() Worker.java:55
> I started profiling Yourkit when the build hung. It shows the following as the live call stack:
> Call Tree Time (ms) Level
> <All threads> 530944 1
> org.eclipse.linuxtools.internal.docker.core.DockerContainerRefreshManager$ContainerRefreshThread.run() 530086 2
> org.eclipse.equinox.launcher.Main.run(String[]) 436 2
> org.eclipse.core.internal.jobs.Worker.run() 421 2
> I've not found a workaround yet. Killing eclipse and cleaning the workspace sometimes avoids the issue. This issue does not happen in an Eclipse installation where JBoss tools has not been installed
> Eclipse remains responsive until another call to 'Server.getModules' happens. Below is the deadlock trace from when Eclipse completely hangs:
> Frozen threads found (potential deadlock)
> It seems that the following threads have not changed their stack for more than 10 seconds.
> These threads are possibly (but not necessarily!) in a deadlock or hung.
> main <--- Frozen for at least 2m 21s
> org.eclipse.wst.server.core.internal.Server.getModules() Server.java:2527
> org.jboss.ide.eclipse.as.ui.actions.ChangeTimeStampActionDelegate.getServers(IModule) ChangeTimeStampActionDelegate.java:150
> org.jboss.ide.eclipse.as.ui.actions.ChangeTimeStampActionDelegate.buildActions() ChangeTimeStampActionDelegate.java:112
> org.jboss.ide.eclipse.as.ui.actions.ChangeTimeStampActionDelegate.selectionChanged(IAction, ISelection) ChangeTimeStampActionDelegate.java:69
> org.eclipse.ui.internal.PluginAction.refreshEnablement() PluginAction.java:206
> org.eclipse.ui.internal.PluginAction.selectionChanged(ISelection) PluginAction.java:273
> org.eclipse.ui.internal.PluginAction.selectionChanged(IWorkbenchPart, ISelection) PluginAction.java:297
> org.eclipse.ui.internal.e4.compatibility.SelectionService.notifyListeners(IWorkbenchPart, ISelection, ListenerList) SelectionService.java:259
> org.eclipse.ui.internal.e4.compatibility.SelectionService.handleSelectionChanged(MPart, Object, boolean) SelectionService.java:108
> org.eclipse.ui.internal.e4.compatibility.SelectionService.access$0(SelectionService, MPart, Object, boolean) SelectionService.java:92
> org.eclipse.ui.internal.e4.compatibility.SelectionService$1.selectionChanged(MPart, Object) SelectionService.java:67
> org.eclipse.e4.ui.internal.workbench.SelectionAggregator$2.run() SelectionAggregator.java:126
> org.eclipse.core.runtime.SafeRunner.run(ISafeRunnable) SafeRunner.java:42
> org.eclipse.e4.ui.internal.workbench.SelectionAggregator.notifyListeners(MPart, Object) SelectionAggregator.java:123
> org.eclipse.e4.ui.internal.workbench.SelectionAggregator.access$6(SelectionAggregator, MPart, Object) SelectionAggregator.java:121
> org.eclipse.e4.ui.internal.workbench.SelectionAggregator$7$1.run() SelectionAggregator.java:231
> org.eclipse.e4.core.contexts.RunAndTrack.runExternalCode(Runnable) RunAndTrack.java:56
> org.eclipse.e4.ui.internal.workbench.SelectionAggregator$7.changed(IEclipseContext) SelectionAggregator.java:228
> org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(ContextChangeEvent) TrackableComputationExt.java:114
> org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(Set) EclipseContext.java:343
> org.eclipse.e4.core.internal.contexts.EclipseContext.set(String, Object) EclipseContext.java:358
> org.eclipse.e4.ui.internal.workbench.SelectionServiceImpl.setSelection(Object) SelectionServiceImpl.java:31
> org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.selectionChanged(SelectionChangedEvent) CompatibilityPart.java:450
> org.eclipse.jface.viewers.Viewer$1.run() Viewer.java:158
> org.eclipse.core.runtime.SafeRunner.run(ISafeRunnable) SafeRunner.java:42
> org.eclipse.ui.internal.JFaceUtil$1.run(ISafeRunnable) JFaceUtil.java:50
> org.eclipse.jface.util.SafeRunnable.run(ISafeRunnable) SafeRunnable.java:173
> org.eclipse.jface.viewers.Viewer.fireSelectionChanged(SelectionChangedEvent) Viewer.java:155
> org.eclipse.jface.viewers.StructuredViewer.updateSelection(ISelection) StructuredViewer.java:2191
> org.eclipse.jface.viewers.StructuredViewer.handleSelect(SelectionEvent) StructuredViewer.java:1229
> org.eclipse.jface.viewers.StructuredViewer$4.widgetSelected(SelectionEvent) StructuredViewer.java:1258
> org.eclipse.jface.util.OpenStrategy.fireSelectionEvent(SelectionEvent) OpenStrategy.java:242
> org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy, SelectionEvent) OpenStrategy.java:236
> org.eclipse.jface.util.OpenStrategy$1.handleEvent(Event) OpenStrategy.java:405
> org.eclipse.swt.widgets.EventTable.sendEvent(Event) EventTable.java:84
> org.eclipse.swt.widgets.Display.sendEvent(EventTable, Event) Display.java:4418
> org.eclipse.swt.widgets.Widget.sendEvent(Event) Widget.java:1079
> org.eclipse.swt.widgets.Display.runDeferredEvents() Display.java:4236
> org.eclipse.swt.widgets.Display.readAndDispatch() Display.java:3824
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run() PartRenderingEngine.java:1121
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm, Runnable) Realm.java:336
> org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(MApplicationElement, IEclipseContext) PartRenderingEngine.java:1022
> org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(MApplicationElement) E4Workbench.java:150
> org.eclipse.ui.internal.Workbench$5.run() Workbench.java:693
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm, Runnable) Realm.java:336
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) Workbench.java:610
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) PlatformUI.java:148
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IApplicationContext) IDEApplication.java:138
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Object) EclipseAppHandle.java:196
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Object) EclipseAppLauncher.java:134
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Object) EclipseAppLauncher.java:104
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(Object) EclipseStarter.java:388
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(String[], Runnable) EclipseStarter.java:243
> sun.reflect.NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) NativeMethodAccessorImpl.java (native)
> sun.reflect.NativeMethodAccessorImpl.invoke(Object, Object[]) NativeMethodAccessorImpl.java:62
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Object, Object[]) DelegatingMethodAccessorImpl.java:43
> java.lang.reflect.Method.invoke(Object, Object[]) Method.java:498
> org.eclipse.equinox.launcher.Main.invokeFramework(String[], URL[]) Main.java:673
> org.eclipse.equinox.launcher.Main.basicRun(String[]) Main.java:610
> org.eclipse.equinox.launcher.Main.run(String[]) Main.java:1519
> Worker-33 <--- Frozen for at least 14m 43s
> org.eclipse.wst.server.core.internal.Server.getModules() Server.java:2526
> org.eclipse.wst.server.core.internal.Server.visit(IModuleVisitor, IProgressMonitor) Server.java:3035
> org.eclipse.wst.server.core.internal.Server$ResourceChangeJob.run(IProgressMonitor) Server.java:228
> org.eclipse.core.internal.jobs.Worker.run() Worker.java:55
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (JBIDE-24188) CDKv3 terminal output in IDE is ugly when using hyperv
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24188?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-24188:
--------------------------------
Fix Version/s: 4.5.0.AM1
(was: 4.4.4.Final)
> CDKv3 terminal output in IDE is ugly when using hyperv
> ------------------------------------------------------
>
> Key: JBIDE-24188
> URL: https://issues.jboss.org/browse/JBIDE-24188
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Environment: Windows 10, x86_64, hyper V.
> Reporter: Ondrej Dockal
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.5.0.AM1
>
> Attachments: Terminal-HyperV.png, cdk3-hyperv-terminal
>
>
> While starting/stopping CDKv3 server adapter, you can observe flashing window (coming from hyperV) in terminal tab. The output looks bit ugly, there is pretty much space. When starting/stoping minishift from windows command prompt, you can see such blue flashing/blinking window, too. When I tried cygwin terminal, this did not happen. I am not sure if we can do anything about it, it seems like upstream/system issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months