July 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-20292) Remove MaxPermSize from server scripts when Java 9 is used

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20292?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-20292: ------------------------------------- This task is impossible to accomplish until there exists a java9 execution environment. As of now there's really no real way for me to figure out that a java9 vm is actually java 9, at least not through the interfaces. In the past, I dug further to try to see how they actually get the java version from various jre locations, and what they do is actually run a java process in the background and sysout all the system properties and pull the java version from that. Java9 does not have the same system properties, and so there's really no way for me to get access or determine that it's actually java9. > Remove MaxPermSize from server scripts when Java 9 is used > ---------------------------------------------------------- > > Key: JBIDE-20292 > URL: https://issues.jboss.org/browse/JBIDE-20292 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.3.0.Beta1 > Reporter: Martin Malina > Assignee: Rob Stryker > Labels: Java9 > Fix For: 4.3.x > > > I'm not sure how easy this will be, but I think we need some way to do this. > Right now when you set up your WildFly 9 to use JDK 9, it will not start because MaxPermSize is no longer allowed as an argument. > The server will fail to start with this: > {code} > Unrecognized VM option 'MaxPermSize=256m' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} > In JBIDE-19049 we concluded that for now the workaround is to remove that parameter from Launch config manually if needed. This still works, but it would be best if we could somehow detect which version of Java is to be used and adjust the script accordingly. I know it can be tricky, especially when you use an exec env with the server and not a specific JVM directly. > One option would be to check for permgen support beforehand. But a problem I can see is that the exec env can change between server setup and server start, so we would need to check right before the start. Something like what they do here - via a script: > https://answers.atlassian.com/questions/17903656/java-warning-ignoring-op... > Maybe checking this at the time of server setup would still be better than nothing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20292) Remove MaxPermSize from server scripts when Java 9 is used

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20292?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-20292: -------------------------------- Fix Version/s: 4.3.x > Remove MaxPermSize from server scripts when Java 9 is used > ---------------------------------------------------------- > > Key: JBIDE-20292 > URL: https://issues.jboss.org/browse/JBIDE-20292 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Affects Versions: 4.3.0.Beta1 > Reporter: Martin Malina > Assignee: Rob Stryker > Labels: Java9 > Fix For: 4.3.x > > > I'm not sure how easy this will be, but I think we need some way to do this. > Right now when you set up your WildFly 9 to use JDK 9, it will not start because MaxPermSize is no longer allowed as an argument. > The server will fail to start with this: > {code} > Unrecognized VM option 'MaxPermSize=256m' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} > In JBIDE-19049 we concluded that for now the workaround is to remove that parameter from Launch config manually if needed. This still works, but it would be best if we could somehow detect which version of Java is to be used and adjust the script accordingly. I know it can be tricky, especially when you use an exec env with the server and not a specific JVM directly. > One option would be to check for permgen support beforehand. But a problem I can see is that the exec env can change between server setup and server start, so we would need to check right before the start. Something like what they do here - via a script: > https://answers.atlassian.com/questions/17903656/java-warning-ignoring-op... > Maybe checking this at the time of server setup would still be better than nothing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20082) Application wizard: it's not userfriendly

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20082?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-20082: ------------------------------------------ For 4.3.0.Beta2 i moved the "Details" button to the details group and renamed it to "Defined Resources" !defined-resources-button.png! I also added a combo to select the project that we want to create the app in: !projects-combo.png! ...and a link to create/delete projects. Postponing the rest. > Application wizard: it's not userfriendly > ----------------------------------------- > > Key: JBIDE-20082 > URL: https://issues.jboss.org/browse/JBIDE-20082 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Andre Dietisheim > Assignee: Max Rydahl Andersen > Labels: application_wizard, openshift_v3 > Fix For: 4.3.0.CR1 > > Attachments: defined-resources-button.png, explanation-for-labels.png, projects-combo.png, template-resource-details.png > > > The feedback from various sources says that the current implementation of the application wizard that creates an application on OpenShift v3 via templates is not userfriendly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20082) Application wizard: it's not userfriendly

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20082?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-20082: ------------------------------------- Attachment: defined-resources-button.png projects-combo.png > Application wizard: it's not userfriendly > ----------------------------------------- > > Key: JBIDE-20082 > URL: https://issues.jboss.org/browse/JBIDE-20082 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Andre Dietisheim > Assignee: Max Rydahl Andersen > Labels: application_wizard, openshift_v3 > Fix For: 4.3.0.CR1 > > Attachments: defined-resources-button.png, explanation-for-labels.png, projects-combo.png, template-resource-details.png > > > The feedback from various sources says that the current implementation of the application wizard that creates an application on OpenShift v3 via templates is not userfriendly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20217) JDT Debug can not connect/list VM started with suspend=y

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20217?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-20217: ------------------------------------- So, I'm not able to actually replicate it on my OS (Linux rawbdor 3.19.3-200.fc21.x86_64 #1 SMP Thu Mar 26 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux) It never enters the lines requested with the process that's started with suspend=y until after a debugger is connected. So that would explain why I'm not seeing any logs filling up. I can look into making sure the logs don't fill up if a user leaves a suspend=y process running without connecting a debugger for an extended period of time, but other than that, I'd say this is functioning as expected. > JDT Debug can not connect/list VM started with suspend=y > -------------------------------------------------------- > > Key: JBIDE-20217 > URL: https://issues.jboss.org/browse/JBIDE-20217 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: common/jst/core > Affects Versions: 4.3.0.Beta1 > Reporter: Aslak Knutsen > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.3.0.CR1 > > > Having a VM started with suspend=y cause the following error to be logged from https://github.com/jbosstools/jbosstools-base/blob/master/common/plugins/... due to Exception thrown in ToolsCore.getJvmArgs > Seemingly JVMStat can not connect to a suspended VM. > {code} > eclipse.buildId=4.5.0.I20150603-2000 > java.version=1.8.0_45 > java.vendor=Oracle Corporation > BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US > Command-line arguments: -os linux -ws gtk -arch x86_64 > org.jboss.tools.common.jdt.debug > Error > Wed Jul 08 17:16:00 CEST 2015 > {code} > {code} > java.lang.reflect.InvocationTargetException > 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:497) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getJvmArgs(Tools.java:780) > at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getJvmArgs(ToolsCore.java:98) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModelsUsingTools(RemoteDebugActivator.java:166) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModel(RemoteDebugActivator.java:145) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModels(RemoteDebugActivator.java:132) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:193) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:227) > at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator.discoverRemoteApplication(RemoteDebugUIActivator.java:137) > at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator$1.run(RemoteDebugUIActivator.java:93) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > Caused by: sun.jvmstat.monitor.MonitorException: Could not synchronize with target > at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.synchWithTarget(PerfDataBuffer.java:277) > at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.buildMonitorMap(PerfDataBuffer.java:131) > at sun.jvmstat.perfdata.monitor.PerfDataBufferImpl.findByName(PerfDataBufferImpl.java:241) > at sun.jvmstat.perfdata.monitor.AbstractPerfDataBuffer.findByName(AbstractPerfDataBuffer.java:100) > at sun.jvmstat.perfdata.monitor.AbstractMonitoredVm.findByName(AbstractMonitoredVm.java:85) > at sun.jvmstat.monitor.MonitoredVmUtil.jvmArgs(MonitoredVmUtil.java:145) > ... 14 more > Root exception: > sun.jvmstat.monitor.MonitorException: Could not synchronize with target > at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.synchWithTarget(PerfDataBuffer.java:277) > at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.buildMonitorMap(PerfDataBuffer.java:131) > at sun.jvmstat.perfdata.monitor.PerfDataBufferImpl.findByName(PerfDataBufferImpl.java:241) > at sun.jvmstat.perfdata.monitor.AbstractPerfDataBuffer.findByName(AbstractPerfDataBuffer.java:100) > at sun.jvmstat.perfdata.monitor.AbstractMonitoredVm.findByName(AbstractMonitoredVm.java:85) > at sun.jvmstat.monitor.MonitoredVmUtil.jvmArgs(MonitoredVmUtil.java:145) > 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:497) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getJvmArgs(Tools.java:780) > at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getJvmArgs(ToolsCore.java:98) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModelsUsingTools(RemoteDebugActivator.java:166) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModel(RemoteDebugActivator.java:145) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModels(RemoteDebugActivator.java:132) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:193) > at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:227) > at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator.discoverRemoteApplication(RemoteDebugUIActivator.java:137) > at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator$1.run(RemoteDebugUIActivator.java:93) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20082) Application wizard: it's not userfriendly

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20082?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-20082: ------------------------------------- Fix Version/s: 4.3.0.CR1 (was: 4.3.0.Beta2) > Application wizard: it's not userfriendly > ----------------------------------------- > > Key: JBIDE-20082 > URL: https://issues.jboss.org/browse/JBIDE-20082 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Andre Dietisheim > Assignee: Max Rydahl Andersen > Labels: application_wizard, openshift_v3 > Fix For: 4.3.0.CR1 > > Attachments: explanation-for-labels.png, template-resource-details.png > > > The feedback from various sources says that the current implementation of the application wizard that creates an application on OpenShift v3 via templates is not userfriendly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20002) Explorer: Delete multiple OpenShift resources at once

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20002?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-20002: ------------------------------------------ we went out of time for this in 4.3.0.Beta2, postponing > Explorer: Delete multiple OpenShift resources at once > ----------------------------------------------------- > > Key: JBIDE-20002 > URL: https://issues.jboss.org/browse/JBIDE-20002 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Marián Labuda > Priority: Minor > Labels: explorer, openshift_v3 > Fix For: 4.3.0.CR1 > > > It would be nice to have a feature allowing removing more resources at once: > 1) Multiselect on some specific type of resource (e.g. pods) and deleting them via context menu "Delete resources..." which pop up dialog "Do you really want to delete selected resources?" with Yes, No, Cancel. > 2) Deleting specific resources - from context menu on Pods / Builds etc. I would like to choose "Delete resources..." to remove all underlying resources. > 3) Delete all resources. Should be accessible from context menu of a project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20069) OpenShift Feature is missing (in Installation Details)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20069?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-20069: ------------------------------------- Fix Version/s: 4.3.0.CR1 (was: 4.3.0.Beta2) > OpenShift Feature is missing (in Installation Details) > ------------------------------------------------------ > > Key: JBIDE-20069 > URL: https://issues.jboss.org/browse/JBIDE-20069 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Marián Labuda > Priority: Critical > Labels: openshift_v3 > Fix For: 4.3.0.CR1 > > Attachments: missing-openshift-feature.png > > > In Installation Details under tab Features should be located OpenShift feature (or OpenShift UI feature). But it is missing in JBT (also in JBDS). > !missing-openshift-feature.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20069) OpenShift Feature is missing (in Installation Details)

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20069?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-20069: ------------------------------------------ we went out of time for this in 4.3.0.Beta2, postponing > OpenShift Feature is missing (in Installation Details) > ------------------------------------------------------ > > Key: JBIDE-20069 > URL: https://issues.jboss.org/browse/JBIDE-20069 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Marián Labuda > Priority: Critical > Labels: openshift_v3 > Fix For: 4.3.0.CR1 > > Attachments: missing-openshift-feature.png > > > In Installation Details under tab Features should be located OpenShift feature (or OpenShift UI feature). But it is missing in JBT (also in JBDS). > !missing-openshift-feature.png! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20099) enable a logstream for Openshift Pods

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20099?page=com.atlassian.jira.plugi... ] Andre Dietisheim commented on JBIDE-20099: ------------------------------------------ we went out of time for this in 4.3.0.Beta2, postponing > enable a logstream for Openshift Pods > ------------------------------------- > > Key: JBIDE-20099 > URL: https://issues.jboss.org/browse/JBIDE-20099 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Affects Versions: 4.3.0.Beta1 > Reporter: Diógenes Rettori > Fix For: 4.3.0.CR1 > > > enable the eclipse console to show > oc get logs <pod> > oc get build-logs <build> > You click on the pod, then right-click show logs, or double click go to logs... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues July 2015