June 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-20996) DV 6.2 is shipped withou EAP. Can we do something about it in context of Download Runtime wizard?

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20996?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-20996: -------------------------------- Fix Version/s: 4.5.0.AM2 (was: 4.5.0.AM1) > DV 6.2 is shipped withou EAP. Can we do something about it in context of Download Runtime wizard? > ------------------------------------------------------------------------------------------------- > > Key: JBIDE-20996 > URL: https://issues.jboss.org/browse/JBIDE-20996 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: runtime-detection, upstream > Affects Versions: 4.3.0.Final > Reporter: Radim Hopp > Assignee: Rob Stryker > Fix For: 4.5.0.AM2 > > > It's great that now, with JBIDE-19852 and JBIDE-20769 resolved, one can download DV 6.2 using Download Runtimes wizard and have the installation path pre-filled. But the DV 6.2 installator requires EAP 6.4 already present on user's machine (and the installation path must point to its JBOSS_HOME). If user does not have EAP 6.4, he has to exit wizard, install EAP 6.4 and then download (again) and install DV 6.2. > Is there anything we could do to make this workflow easier. > Maybe at least tell user to install EAP 6.4 prior downloading DV 6.2? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20996) DV 6.2 is shipped withou EAP. Can we do something about it in context of Download Runtime wizard?

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20996?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-20996: -------------------------------- Fix Version/s: 4.5.0.AM1 (was: 4.4.x) > DV 6.2 is shipped withou EAP. Can we do something about it in context of Download Runtime wizard? > ------------------------------------------------------------------------------------------------- > > Key: JBIDE-20996 > URL: https://issues.jboss.org/browse/JBIDE-20996 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: runtime-detection, upstream > Affects Versions: 4.3.0.Final > Reporter: Radim Hopp > Assignee: Rob Stryker > Fix For: 4.5.0.AM1 > > > It's great that now, with JBIDE-19852 and JBIDE-20769 resolved, one can download DV 6.2 using Download Runtimes wizard and have the installation path pre-filled. But the DV 6.2 installator requires EAP 6.4 already present on user's machine (and the installation path must point to its JBOSS_HOME). If user does not have EAP 6.4, he has to exit wizard, install EAP 6.4 and then download (again) and install DV 6.2. > Is there anything we could do to make this workflow easier. > Maybe at least tell user to install EAP 6.4 prior downloading DV 6.2? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24593) Reconnect to jmx yields progress monitor errors

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24593?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-24593. --------------------------------- Assignee: Rob Stryker Resolution: Done I've fixed it as much as I can, but I doubt you'll be pleased. There's just no way to add a progress monitor directly into the MBeanserverConnection since it's an official java api. I can't keep any more track than 1 request = bump the progmon, and since each of these nodes are given their own job with only 1 task per job, it's 0% to 100% immediately. Hard (ie impossible) to report progress on a single task. > Reconnect to jmx yields progress monitor errors > ----------------------------------------------- > > Key: JBIDE-24593 > URL: https://issues.jboss.org/browse/JBIDE-24593 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jmx > Affects Versions: 4.5.0.AM1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.5.0.AM2 > > Attachments: JMXLoad.mp4 > > > when I connect, expand some nodes, call refresh, collapse them then disconnect then reconnect, all the previously expanded node are loaded with a progress monitor which is not showing progress and stay blocked at 0% -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24593) Reconnect to jmx yields progress monitor errors

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24593?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-24593: ------------------------------------- I'll make a patch here, but, you probably won't be happy with it. The fact is, each node gets its own job, which means they have their own progress monitors. So if you had 5 expanded objectname nodes, you'd now get 5 jobs running at once, and each job will have a very simple progress workflow. See, the MBeanServerConnection API has no notion of progress monitors. It's an official java api, so I can't change the interfaces to respect progress monitors. So what we'll end up with is a few methods that basically begin a progress monitor, move it 5%, then execute their 1 atomic command on the mbean server connection, and then mark the monitor as done. It will behave almost identically to what you see now, except with maybe a label as to what the current task is. You won't be pleased with the outcome, but it will be the best i can do without rewriting official java APIs ;) > Reconnect to jmx yields progress monitor errors > ----------------------------------------------- > > Key: JBIDE-24593 > URL: https://issues.jboss.org/browse/JBIDE-24593 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jmx > Affects Versions: 4.5.0.AM1 > Reporter: Rob Stryker > Fix For: 4.5.0.AM2 > > Attachments: JMXLoad.mp4 > > > when I connect, expand some nodes, call refresh, collapse them then disconnect then reconnect, all the previously expanded node are loaded with a progress monitor which is not showing progress and stay blocked at 0% -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15519) Clean UI and Core dependencies

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15519?page=com.atlassian.jira.plugi... ] Rob Stryker updated JBIDE-15519: -------------------------------- Fix Version/s: 4.5.0.AM2 (was: 4.5.0.AM1) > Clean UI and Core dependencies > ------------------------------ > > Key: JBIDE-15519 > URL: https://issues.jboss.org/browse/JBIDE-15519 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: livereload > Affects Versions: 4.1.0.Final > Reporter: Xavier Coulon > Assignee: Xavier Coulon > Fix For: 4.5.0.AM2 > > > Move all *.ui.* dependencies from livereload.core to livereload.ui -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15519) Clean UI and Core dependencies

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15519?page=com.atlassian.jira.plugi... ] Rob Stryker reassigned JBIDE-15519: ----------------------------------- Assignee: Rob Stryker (was: Xavier Coulon) > Clean UI and Core dependencies > ------------------------------ > > Key: JBIDE-15519 > URL: https://issues.jboss.org/browse/JBIDE-15519 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: livereload > Affects Versions: 4.1.0.Final > Reporter: Xavier Coulon > Assignee: Rob Stryker > Fix For: 4.5.0.AM2 > > > Move all *.ui.* dependencies from livereload.core to livereload.ui -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4386) Please correct launch configuration so WARN is no longer provided by default

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBDS-4386?page=com.atlassian.jira.plugin.... ] Rob Stryker resolved JBDS-4386. ------------------------------- Resolution: Won't Fix For eap 6.x, we're sticking with what is in the command line script. WF 11 and Eap 7.x do not include these flags, so we're good there. > Please correct launch configuration so WARN is no longer provided by default > ---------------------------------------------------------------------------- > > Key: JBDS-4386 > URL: https://issues.jboss.org/browse/JBDS-4386 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: common > Affects Versions: 10.3.0.GA > Environment: DevStudio 10.3, as used with an EAP server. > Reporter: Rick Wagner > Assignee: Rob Stryker > Priority: Minor > Fix For: 11.0.0.AM1 > > > Using default settings, an EAP 6.4 (Fuse) server gives the following WARN in the Console view: > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 > Removal of the following param from VM arguments resolves the issue: > -XX:MaxPermSize=256m -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24080) release webtools site for Eclipse 4.5 Oxygen to so WTP 3.9 discovery upstream can find it

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24080?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-24080: ------------------------------------ I've updated the symlink to CI to point to dev milestone as AM1 is being released. > release webtools site for Eclipse 4.5 Oxygen to so WTP 3.9 discovery upstream can find it > ----------------------------------------------------------------------------------------- > > Key: JBIDE-24080 > URL: https://issues.jboss.org/browse/JBIDE-24080 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server, updatesite, upstream > Affects Versions: 4.5.0.AM1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.5.0.AM1 > > > Need a semi-working placeholder (even if it's a CI build) so that WTP can resolve a valid site for server adapters. > Content that needs to be copied is here: > http://download.jboss.org/jbosstools/oxygen/snapshots/updates/ > Once we release 4.5.0.Final, we can then update the symlink to point here: > http://download.jboss.org/jbosstools/oxygen/stable/updates/ > Upstream issue: > https://bugs.eclipse.org/513578 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4065) DevSuite 1.1 Installer unfriendly when 1.0 present

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBDS-4065?page=com.atlassian.jira.plugin.... ] Rob Stryker resolved JBDS-4065. ------------------------------- Resolution: Out of Date This is a bit out of date, so we won't be fixing these specific builds. Let's see if things improve in future versions. > DevSuite 1.1 Installer unfriendly when 1.0 present > -------------------------------------------------- > > Key: JBDS-4065 > URL: https://issues.jboss.org/browse/JBDS-4065 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: cdk, platform-installer > Affects Versions: 10.1.0.GA > Environment: Windows 10, DevSuite Installer 1.0 had been run > Reporter: Rick Wagner > Assignee: Denis Golovin > Fix For: 11.0.0.AM1 > > > When running the DevSuite 1.1 installer, DevStudio is not connected to the installed CDK. > Observations: > - All components removed before installation, does not help. (VirtualBox and Vagrant using Add/Remove programs, everything else directory-deleted, Environment variables cleaned). > - DevStudio says it can't start the Container Development Environment server. ('Failed to find Vagrant!' reads the error). If I open Launch Configuration, it lists the Main as "C:\HashiCorp\Vagrant\bin\vagrant.exe", which is not in the installation directory. > - It was noted that DevStudio marked itself 'completed' before Vagrant was installed. How does DevStudio know where Vagrant is? > - It's noted that DevStudio 'remembers' user settings (i.e. CDK registration user/password) from previous attempts. Where is this information kept? I must've missed something in cleanup. > - Tried full suite installation, then deleting DevStudio, then re-installing. (Hoping DevStudio would then find Vagrant in the right location, because it followed Vagrant's installation.) Result: No Container Development Environment server is present in 'server' view. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4180) ClassNotFoundException thrown on devstudio start up

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBDS-4180?page=com.atlassian.jira.plugin.... ] Rob Stryker updated JBDS-4180: ------------------------------ Labels: affects_documentation (was: ) > ClassNotFoundException thrown on devstudio start up > --------------------------------------------------- > > Key: JBDS-4180 > URL: https://issues.jboss.org/browse/JBDS-4180 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: foundation, upstream > Affects Versions: 10.2.0.GA > Environment: Fedora 24, > openjdk version "1.8.0_102" > OpenJDK Runtime Environment (build 1.8.0_102-b14) > Reporter: Marián Labuda > Assignee: Rob Stryker > Labels: affects_documentation > Fix For: 11.0.0.AM1 > > > When starting latest DevStudio 10.2.0.GA (build ID GA-v20161116-0039-B6472) I get following error in console output > {code} > SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] > Noop constructor > java.lang.ClassNotFoundException: sun.jvmstat.monitor.MonitoredHost > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:132) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.invokeGetMonitoredHost(Tools.java:513) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.validateClassPathAndLibraryPath(Tools.java:365) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.reset(Tools.java:115) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.<init>(Tools.java:82) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.getInstance(Tools.java:73) > at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getActiveProcessIds(ToolsCore.java:179) > at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler.updatesActiveJvms(JvmAttachHandler.java:100) > at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler$1.run(JvmAttachHandler.java:78) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > java.lang.ClassNotFoundException: sun.jvmstat.monitor.MonitoredHost > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:132) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.invokeGetMonitoredHost(Tools.java:513) > at org.jboss.tools.common.jdt.debug.tools.internal.Tools.invokeActiveVms(Tools.java:525) > at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getActiveProcessIds(ToolsCore.java:179) > at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler.updatesActiveJvms(JvmAttachHandler.java:100) > at org.jboss.tools.jmx.jvmmonitor.internal.tools.JvmAttachHandler$1.run(JvmAttachHandler.java:78) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} > problem is with openjdk version. With the lates 1.8.0_111 it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 June 2017