[JBoss JIRA] (JBDS-4050) CDK 2.2 installation failed in devsuite 1.1.0-GA-20160915
by Budh Ram Gurung (JIRA)
[ https://issues.jboss.org/browse/JBDS-4050?page=com.atlassian.jira.plugin.... ]
Budh Ram Gurung commented on JBDS-4050:
---------------------------------------
Yes [~dgolovin]. "C++ redistribution package x64 2015" couldn't work. Also, upstream issue means the same I believe. https://github.com/mitchellh/vagrant/issues/6852
> CDK 2.2 installation failed in devsuite 1.1.0-GA-20160915
> ---------------------------------------------------------
>
> Key: JBDS-4050
> URL: https://issues.jboss.org/browse/JBDS-4050
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 10.1.0.GA
> Environment: **Operating System**
> Windows 10 Pro 64 Bit
> **Devsuite version**
> Devsuite 1.1.0-GA-20160915-140
> Reporter: Budh Ram Gurung
> Assignee: Denis Golovin
> Fix For: 10.2.0.AM1
>
> Attachments: 1.devsuite.PNG, 2.c++.PNG, 3.vagrant_cli.PNG, install-iteration1.log, install.log, vagrant-up-debug-log.txt
>
>
> After passing through registration, on clicking 'Install' button in the installer window, the CDK 2.2 get failed message.
> Check the attached screenshots.
> I also tried to add vagrant box through cygwin shell but getting some `eventmachine.so` related error.
> *NOTE*: I am able to successfully add the cdk box on Vagrant 1.7.4 version.
> Other information, I had following things pre-installed before running the installer:
> - Docker toolbox (probably it remain there when I was trying it last time)
> - Vagrant 1.8.1
> - Cygwin
> - VirtualBox 5.0.26
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23205) Allow to lookup ReplicationController for a Service without having to get to the pods
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23205?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23205:
-------------------------------------
Story Points: 4
Sprint: devex #120 September 2016
> Allow to lookup ReplicationController for a Service without having to get to the pods
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-23205
> URL: https://issues.jboss.org/browse/JBIDE-23205
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.4.2.AM1
>
>
> When looking up a replication for a service, the current approach that we have requires us to go and get the pods that match the service we're starting with. Once we have these we then can determine what replication controller controls them.
> This only works if a replication controller is set to have replicas. If there are none there are no pods and we're thus stuck.
> The match can be done directly: match the labels of the pod templates within the replication controller against the service we're starting with.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23205) Allow to lookup ReplicationController for a Service without having to get to the pods
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23205?page=com.atlassian.jira.plugi... ]
Andre Dietisheim reassigned JBIDE-23205:
----------------------------------------
Assignee: Andre Dietisheim
> Allow to lookup ReplicationController for a Service without having to get to the pods
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-23205
> URL: https://issues.jboss.org/browse/JBIDE-23205
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.Final
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.4.2.AM1
>
>
> When looking up a replication for a service, the current approach that we have requires us to go and get the pods that match the service we're starting with. Once we have these we then can determine what replication controller controls them.
> This only works if a replication controller is set to have replicas. If there are none there are no pods and we're thus stuck.
> The match can be done directly: match the labels of the pod templates within the replication controller against the service we're starting with.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23205) Allow to lookup ReplicationController for a Service without having to get to the pods
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23205?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23205:
-------------------------------------
Fix Version/s: 4.4.2.AM1
> Allow to lookup ReplicationController for a Service without having to get to the pods
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-23205
> URL: https://issues.jboss.org/browse/JBIDE-23205
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.Final
> Reporter: Andre Dietisheim
> Fix For: 4.4.2.AM1
>
>
> When looking up a replication for a service, the current approach that we have requires us to go and get the pods that match the service we're starting with. Once we have these we then can determine what replication controller controls them.
> This only works if a replication controller is set to have replicas. If there are none there are no pods and we're thus stuck.
> The match can be done directly: match the labels of the pod templates within the replication controller against the service we're starting with.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23205) Allow to lookup ReplicationController for a Service without having to get to the pods
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23205?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-23205:
-------------------------------------
Affects Version/s: 4.4.1.Final
(was: 4.4.2.AM2)
> Allow to lookup ReplicationController for a Service without having to get to the pods
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-23205
> URL: https://issues.jboss.org/browse/JBIDE-23205
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.4.1.Final
> Reporter: Andre Dietisheim
> Fix For: 4.4.2.AM1
>
>
> When looking up a replication for a service, the current approach that we have requires us to go and get the pods that match the service we're starting with. Once we have these we then can determine what replication controller controls them.
> This only works if a replication controller is set to have replicas. If there are none there are no pods and we're thus stuck.
> The match can be done directly: match the labels of the pod templates within the replication controller against the service we're starting with.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23205) Allow to lookup ReplicationController for a Service without having to get to the pods
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-23205:
----------------------------------------
Summary: Allow to lookup ReplicationController for a Service without having to get to the pods
Key: JBIDE-23205
URL: https://issues.jboss.org/browse/JBIDE-23205
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.4.2.AM2
Reporter: Andre Dietisheim
When looking up a replication for a service, the current approach that we have requires us to go and get the pods that match the service we're starting with. Once we have these we then can determine what replication controller controls them.
This only works if a replication controller is set to have replicas. If there are none there are no pods and we're thus stuck.
The match can be done directly: match the labels of the pod templates within the replication controller against the service we're starting with.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ERT-221) Exception when debugging with chromium [EBZ#494731]
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/ERT-221?page=com.atlassian.jira.plugin.sy... ]
Ilya Buziuk resolved ERT-221.
-----------------------------
Resolution: Done
> Exception when debugging with chromium [EBZ#494731]
> ---------------------------------------------------
>
> Key: ERT-221
> URL: https://issues.jboss.org/browse/ERT-221
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Friendly Jira Robot
> Assignee: Victor Rubezhny
> Labels: 3.8_RC3, Debug, bzira
> Fix For: Neon (4.6) RC3
>
>
> Using EPP JavaScript RC2 package, using "Debug As > Node.js application" on some random file.
> This error seems to happen whenever the program is interrupted, for example because a dependency doesn't compile or whatever.
> Such remote interruption can happen pretty often, the shouldn't be treated as IDE error, but rather caught and presented to the user. Currently, it's logged in the IDE, and AERI suggests to open a ticket for that despite there is nothing wrong in the IDE. This gives an impression that debugger has bugs and this is going to flood AERI with no fair reason.
> --
> eclipse.buildId=4.6.0.I20160519-1730
> java.version=1.8.0_77
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product org.eclipse.epp.package.javascript.product
> Command-line arguments: -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.javascript.product
> org.eclipse.wst.jsdt.chromium.debug.core
> Error
> Fri May 27 11:23:55 CEST 2016
> SDK:org.eclipse.wst.jsdt.chromium.internal.transport.SocketConnection: Exception in message listener
> java.lang.IllegalStateException: Connection not attached
> at org.eclipse.wst.jsdt.chromium.internal.transport.SocketConnection.checkAttached(SocketConnection.java:455)
> at org.eclipse.wst.jsdt.chromium.internal.transport.SocketConnection.send(SocketConnection.java:416)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl$V8CommandOutputImpl.send(StandaloneVmImpl.java:249)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.V8CommandProcessor$HandlerImpl.send(V8CommandProcessor.java:133)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.V8CommandProcessor$HandlerImpl.send(V8CommandProcessor.java:1)
> at org.eclipse.wst.jsdt.chromium.internal.BaseCommandProcessor.send(BaseCommandProcessor.java:75)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.V8CommandProcessor.sendV8CommandAsync(V8CommandProcessor.java:84)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.DebugSession.sendMessageAsync(DebugSession.java:101)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.processor.AfterCompileProcessor.messageReceived(AfterCompileProcessor.java:44)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.DefaultResponseHandler.handleResponseWithHandler(DefaultResponseHandler.java:60)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.V8CommandProcessor$HandlerImpl.acceptNonSeq(V8CommandProcessor.java:145)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.V8CommandProcessor$HandlerImpl.acceptNonSeq(V8CommandProcessor.java:1)
> at org.eclipse.wst.jsdt.chromium.internal.BaseCommandProcessor.processIncoming(BaseCommandProcessor.java:112)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.V8CommandProcessor.processIncomingJson(V8CommandProcessor.java:115)
> at org.eclipse.wst.jsdt.chromium.internal.standalonev8.StandaloneVmImpl$4.messageReceived(StandaloneVmImpl.java:116)
> at org.eclipse.wst.jsdt.chromium.internal.transport.SocketConnection$RegularMessageItem.report(SocketConnection.java:122)
> at org.eclipse.wst.jsdt.chromium.internal.transport.SocketConnection$ResponseDispatcherThread.run(SocketConnection.java:211)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ERT-379) Exceptions while expanding Variables view [EBZ#499600]
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/ERT-379?page=com.atlassian.jira.plugin.sy... ]
Ilya Buziuk updated ERT-379:
----------------------------
Sprint: (was: devex #121 October 2016)
> Exceptions while expanding Variables view [EBZ#499600]
> ------------------------------------------------------
>
> Key: ERT-379
> URL: https://issues.jboss.org/browse/ERT-379
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Friendly Jira Robot
> Assignee: Ilya Buziuk
> Labels: 3.8.1, Debug, bzira
> Fix For: Neon.1 (4.6)
>
>
> Steps to reproduce:
> -------------------
> 1) import: https://github.com/ibuziuk/myRESTApp
> 2) server.js -> Debug As -> Node.js Application
> 3) Expand various items variables view.
> Stack trace:
> ================================================
> org.eclipse.wst.jsdt.chromium.internal.protocolparser.implutil.CommonImpl$ParseRuntimeException: On demand parsing failed for {"ref":118,"propertyType":2,"attributes":7}
> at org.eclipse.wst.jsdt.chromium.internal.protocolparser.dynamicimpl.DynamicParserImpl$LazyParseFieldMethodHandler.handle(DynamicParserImpl.java:696)
> at org.eclipse.wst.jsdt.chromium.internal.protocolparser.dynamicimpl.JsonInvocationHandler.invoke(JsonInvocationHandler.java:35)
> at com.sun.proxy.$Proxy88.name(Unknown Source)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.protocol.V8ProtocolUtil$PropertyNameGetter$SubpropertyNameGetter.getName(V8ProtocolUtil.java:216)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.protocol.V8ProtocolUtil$PropertyNameGetter$SubpropertyNameGetter.getName(V8ProtocolUtil.java:1)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.protocol.V8ProtocolUtil.extractProperty(V8ProtocolUtil.java:150)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.protocol.V8ProtocolUtil.putMirror(V8ProtocolUtil.java:134)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.protocol.V8ProtocolUtil.extractObjectProperties(V8ProtocolUtil.java:94)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.SubpropertiesMirror$JsonBased.getProperties(SubpropertiesMirror.java:69)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsObjectBase$1.runSync(JsObjectBase.java:176)
> at org.eclipse.wst.jsdt.chromium.util.AsyncFuture$SyncOperation.execute(AsyncFuture.java:171)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsObjectBase.startPropertyLoadOperation(JsObjectBase.java:199)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsObjectBase.getPropertyData(JsObjectBase.java:138)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsObjectBase.getBasicPropertyData(JsObjectBase.java:159)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl.getAdditionalPropertyData(JsFunctionImpl.java:82)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl.getVariableScopes(JsFunctionImpl.java:47)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl.access$2(JsFunctionImpl.java:46)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl$1.getScopes(JsFunctionImpl.java:127)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.Value.calculateFunctionScopesVariable(Value.java:95)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.Value.calculateVariables(Value.java:74)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.ValueBase$ValueWithLazyVariables.getVariables(ValueBase.java:77)
> at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.getValueChildren(VariableContentProvider.java:170)
> at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.getAllChildren(VariableContentProvider.java:87)
> at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.getChildCount(VariableContentProvider.java:49)
> at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildCount(ElementContentProvider.java:118)
> at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$2.run(ElementContentProvider.java:67)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: org.eclipse.wst.jsdt.chromium.internal.protocolparser.JsonProtocolParseException: Field is not optional: name (in type org.eclipse.wst.jsdt.chromium.internal.v8native.protocol.input.data.PropertyObject)
> at org.eclipse.wst.jsdt.chromium.internal.protocolparser.dynamicimpl.DynamicParserImpl$LazyParseFieldMethodHandler.parse(DynamicParserImpl.java:729)
> at org.eclipse.wst.jsdt.chromium.internal.protocolparser.dynamicimpl.DynamicParserImpl$LazyParseFieldMethodHandler.parse(DynamicParserImpl.java:715)
> at org.eclipse.wst.jsdt.chromium.internal.protocolparser.dynamicimpl.DynamicParserImpl$LazyParseFieldMethodHandler.handle(DynamicParserImpl.java:694)
> ... 26 more
> ================================================
> java.lang.NullPointerException
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl.getAdditionalPropertyData(JsFunctionImpl.java:82)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl.getVariableScopes(JsFunctionImpl.java:47)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl.access$2(JsFunctionImpl.java:46)
> at org.eclipse.wst.jsdt.chromium.internal.v8native.value.JsFunctionImpl$1.getScopes(JsFunctionImpl.java:127)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.Value.calculateFunctionScopesVariable(Value.java:95)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.Value.calculateVariables(Value.java:74)
> at org.eclipse.wst.jsdt.chromium.debug.core.model.ValueBase$ValueWithLazyVariables.getVariables(ValueBase.java:77)
> at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.getValueChildren(VariableContentProvider.java:170)
> at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.getAllChildren(VariableContentProvider.java:87)
> at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.getChildren(VariableContentProvider.java:57)
> at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.retrieveChildren(ElementContentProvider.java:91)
> at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$1.run(ElementContentProvider.java:44)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months