April 2013 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-14357) Credentials dialog: should get default server if switch from existing to new connection

by Andre Dietisheim (JIRA)

Andre Dietisheim created JBIDE-14357: ---------------------------------------- Summary: Credentials dialog: should get default server if switch from existing to new connection Key: JBIDE-14357 URL: https://issues.jboss.org/browse/JBIDE-14357 Project: Tools (JBoss Tools) Issue Type: Bug Components: openshift Affects Versions: 4.1.0.Beta1 Reporter: Andre Dietisheim Assignee: Andre Dietisheim Priority: Minor Fix For: 4.1.x Attachments: existing-conn-nondefault-server.png, new-connection-nondefault-server.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14357) Credentials dialog: should get default server if switch from existing to new connection

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14357?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-14357: ------------------------------------- Attachment: existing-conn-nondefault-server.png new-connection-nondefault-server.png > Credentials dialog: should get default server if switch from existing to new connection > --------------------------------------------------------------------------------------- > > Key: JBIDE-14357 > URL: https://issues.jboss.org/browse/JBIDE-14357 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.1.0.Beta1 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Priority: Minor > Fix For: 4.1.x > > Attachments: existing-conn-nondefault-server.png, new-connection-nondefault-server.png > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14356) GC overhead limit exceeded when adding fileset to LiveReload Server

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14356?page=com.atlassian.jira.plugi... ] Alexey Kazakov updated JBIDE-14356: ----------------------------------- Component/s: livereload > GC overhead limit exceeded when adding fileset to LiveReload Server > ------------------------------------------------------------------- > > Key: JBIDE-14356 > URL: https://issues.jboss.org/browse/JBIDE-14356 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: livereload > Reporter: Stian Thorgersen > > When creating a LiveReload Server and adding a fileset Eclipse hangs consuming a lot of CPU. Eventually the error message "Unhandled event loop exception / GC overhead limit exceeded" is displayed. > From the stack trace while this is going the only interesting thread is: > {code} > "main" prio=10 tid=0x00007ff9a0009800 nid=0x22c2 runnable [0x00007ff9a81fe000] > java.lang.Thread.State: RUNNABLE > at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) > at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8654) > at org.eclipse.swt.widgets.Display.eventProc(Display.java:1243) > at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) > at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2283) > at org.eclipse.swt.widgets.Shell.setVisible(Shell.java:2153) > at org.eclipse.swt.widgets.Shell.open(Shell.java:1546) > at org.eclipse.jface.window.Window.open(Window.java:798) > at org.eclipse.ui.internal.statushandlers.InternalDialog.open(InternalDialog.java:327) > at org.eclipse.ui.internal.statushandlers.WorkbenchStatusDialogManagerImpl.doAddStatusAdapter(WorkbenchStatusDialogManagerImpl.java:270) > at org.eclipse.ui.internal.statushandlers.WorkbenchStatusDialogManagerImpl.addStatusAdapter(WorkbenchStatusDialogManagerImpl.java:197) > at org.eclipse.ui.statushandlers.WorkbenchStatusDialogManager.addStatusAdapter(WorkbenchStatusDialogManager.java:156) > at org.eclipse.ui.statushandlers.WorkbenchErrorHandler.showStatusAdapter(WorkbenchErrorHandler.java:101) > at org.eclipse.ui.statushandlers.WorkbenchErrorHandler.handle(WorkbenchErrorHandler.java:57) > at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.handle(IDEWorkbenchErrorHandler.java:106) > at org.eclipse.ui.internal.WorkbenchErrorHandlerProxy.handle(WorkbenchErrorHandlerProxy.java:36) > at org.eclipse.ui.statushandlers.StatusManager.handle(StatusManager.java:189) > at org.eclipse.ui.statushandlers.StatusManager.handle(StatusManager.java:231) > at org.eclipse.ui.statushandlers.StatusManager.handle(StatusManager.java:242) > at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopException(WorkbenchAdvisor.java:326) > at org.eclipse.ui.internal.ExceptionHandler.handleException(ExceptionHandler.java:65) > at org.eclipse.jface.window.Window.runEventLoop(Window.java:830) > at org.eclipse.jface.window.Window.open(Window.java:802) > at org.jboss.ide.eclipse.archives.webtools.filesets.FilesetActionProvider$1.run(FilesetActionProvider.java:202) > at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) > at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) > at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) > at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) > at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392) > at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3717) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3338) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1108) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:992) > at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:137) > at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:600) > at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) > at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:555) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) > at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) > at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) > at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) > at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) > at org.eclipse.equinox.launcher.Main.run(Main.java:1450) > at org.eclipse.equinox.launcher.Main.main(Main.java:1426) > {code} > I'm running: > * Eclipse Kepler M6 with JBoss Tools 4.1 Alpha 2 > * OpenJDK 1.7.0_21 > * Ubuntu 13.04 > To reproduce create a new LiveReload server. Expand it, right click on 'Filesets' and select 'Create New File Filter'. Then write '/' in 'Root Directory'. Observe that Eclipse now consumes ~100% cpu on all available cores. Wait for a few minutes and the error message mentioned earlier should be displayed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-310) redirect /latest to /reference where the latest released docs can be found

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-310?page=com.atlassian.jira.plug... ] Nick Boldt commented on TOOLSDOC-310: ------------------------------------- [~maxandersen] If you don't like having a backup of the server's HTML content via https://github.com/jbosstools/jbosstools-download.jboss.org then I challenge you to propose a better alternative. Meanwhile, for docs.jboss.org, we ought to have a similar solution to back up the contents on the server so that a) the content can be developed offline and pushed to the server, and b) in case of accidental overwrite / server death, it can be recovered. If not a github repo, then what? > redirect /latest to /reference where the latest released docs can be found > -------------------------------------------------------------------------- > > Key: TOOLSDOC-310 > URL: https://issues.jboss.org/browse/TOOLSDOC-310 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > > for some reason https://github.com/jbosstools/jbosstools-documentation/pull/48 removed the latest link assuming latest is used to point to the nightly build. > That is not what it is for. > It is to point to the latest docs made available. > This link (before: http://docs.jboss.org/tools/latest/) was used to point to the last latest documentation. > I believe this should be put back since this is how other docs refer to the latest version. > We could even go so ar to create a docs.jboss.org/tools/4.0, docs.jboss.org/tools/3.3 etc. folder each with their /latest link in them. > Latest links are trivial to make with sftp as part of the release upload anyway thus should be all possible to script if it is too cumbersome to remember. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14348) BrowserSim address string disappearing

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14348?page=com.atlassian.jira.plugi... ] Alexey Kazakov commented on JBIDE-14348: ---------------------------------------- In iOS Safari you can scroll up to see the address bar. But in BrowserSim you have to click on the notification bar. Scrolling doesnt' help here. > BrowserSim address string disappearing > -------------------------------------- > > Key: JBIDE-14348 > URL: https://issues.jboss.org/browse/JBIDE-14348 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: browsersim > Affects Versions: 4.1.0.Alpha2 > Reporter: Daniel Azarov > Assignee: Yahor Radtsevich > Fix For: 4.1.0.Beta1 > > > Test case: > EXECUTE: > 1. Create project > 2. Create html file: > {code} > <html> > <head> > </head> > <body> > <a id="page1">1 Jump to this place</a> > > aaaaaaaaa asdf ggggggggggg ggggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggg ggggggggggggggggggggg ggggggggggggggggggg ggggggggggggggggggggg > > <a id="page2">2 Jump to this place</a> > > aaaaaaaaa asdf ggggggggggg ggggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggg ggggggggggggggggggggg ggggggggggggggggggg ggggggggggggggggggggg > > <a id="page3">3 Jump to this place</a> > > aaaaaaaaa asdf ggggggggggg ggggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggg ggggggggggggggggggggg ggggggggggggggggggg ggggggggggggggggggggg > > <a id="page4">4 Jump to this place</a> > > aaaaaaaaa asdf ggggggggggg ggggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggg ggggggggggggggggggggg ggggggggggggggggggg ggggggggggggggggggggg > > <a id="page5">5 Jump to this place</a> > > aaaaaaaaa asdf ggggggggggg ggggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggg ggggggggggggggggggggg ggggggggggggggggggg ggggggggggggggggggggg > > <a id="page6">6 Jump to this place</a> > > aaaaaaaaa asdf ggggggggggg ggggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggggg ggggggggggggggggg gggggggggggggggg ggggggggggggggggggggg ggggggggggggggggggg ggggggggggggggggggggg > > </body> > </html> > {code} > 3. Open file with BrowserSim > 4. Try to add #page3 to the address string > FAIL: > Address string disapeared -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14319) CordovaSim: Aerogear default project isn't emulated by CordovaSim

by Yahor Radtsevich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14319?page=com.atlassian.jira.plugi... ] Yahor Radtsevich commented on JBIDE-14319: ------------------------------------------ Please note that Ripple/CordovaSim works with any Cordova 2.x version. How do you know where cordova.js should be placed? I mean is the location/name of cordova.js stored anywhere in the native project settings? Also I expect that presence of cordova.js would be useful for JavaScript tools for code completion. > CordovaSim: Aerogear default project isn't emulated by CordovaSim > ----------------------------------------------------------------- > > Key: JBIDE-14319 > URL: https://issues.jboss.org/browse/JBIDE-14319 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: aerogear-hybrid, browsersim > Reporter: Ilya Buziuk > Assignee: Gorkem Ercan > Fix For: 4.1.0.Beta1 > > > The root of the issue is pretty obvious - there is no cordova.js file in the aerogear project, which is vital for CordovaSim. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-310) redirect /latest to /reference where the latest released docs can be found

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-310?page=com.atlassian.jira.plug... ] Max Rydahl Andersen commented on TOOLSDOC-310: ---------------------------------------------- why ? it serve no purpose besides polluting the git repo. download.jboss.org and the others with their mix of partial live and hosted data is really not nice and something I would like to keep out of our main source repos (like the source for docs). let me rework the patch to match what we had before with proper links and I hope you'll see. > redirect /latest to /reference where the latest released docs can be found > -------------------------------------------------------------------------- > > Key: TOOLSDOC-310 > URL: https://issues.jboss.org/browse/TOOLSDOC-310 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > > for some reason https://github.com/jbosstools/jbosstools-documentation/pull/48 removed the latest link assuming latest is used to point to the nightly build. > That is not what it is for. > It is to point to the latest docs made available. > This link (before: http://docs.jboss.org/tools/latest/) was used to point to the last latest documentation. > I believe this should be put back since this is how other docs refer to the latest version. > We could even go so ar to create a docs.jboss.org/tools/4.0, docs.jboss.org/tools/3.3 etc. folder each with their /latest link in them. > Latest links are trivial to make with sftp as part of the release upload anyway thus should be all possible to script if it is too cumbersome to remember. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-310) redirect /latest to /reference where the latest released docs can be found

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-310?page=com.atlassian.jira.plug... ] Nick Boldt commented on TOOLSDOC-310: ------------------------------------- How about we create a docs.jboss.org folder in the root of jbosstools-documentation/ and move all the web content into there? Then I can put all the symlinks, HTML content, etc. in there and not pollute the root folder. [~mmurray] [~maxandersen] WDYT? > redirect /latest to /reference where the latest released docs can be found > -------------------------------------------------------------------------- > > Key: TOOLSDOC-310 > URL: https://issues.jboss.org/browse/TOOLSDOC-310 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > > for some reason https://github.com/jbosstools/jbosstools-documentation/pull/48 removed the latest link assuming latest is used to point to the nightly build. > That is not what it is for. > It is to point to the latest docs made available. > This link (before: http://docs.jboss.org/tools/latest/) was used to point to the last latest documentation. > I believe this should be put back since this is how other docs refer to the latest version. > We could even go so ar to create a docs.jboss.org/tools/4.0, docs.jboss.org/tools/3.3 etc. folder each with their /latest link in them. > Latest links are trivial to make with sftp as part of the release upload anyway thus should be all possible to script if it is too cumbersome to remember. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13850) Filtering libraries in Source Lookup plugin

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13850?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-13850: --------------------------------------- {quote} based on what ? for some projects this is the right library. {quote} Newer versions are included by default. To include older versions, a user can change a filter using the JBoss Source Lookup preferences page. See the first comment at https://community.jboss.org/en/tools/blog/2012/01/24/jboss-source-lookup {quote} And what is the problem that occurs for these ? That we find the wrong version for a specific class ? {quote} Right. Currently, the JBoss Source Lookup returns the first class it finds (older versions, usually). {quote} Instead of making it for specific libraries could we have a general mechanism that says for AS7 modules we will consider the newest version if we have no other info ? Then over time add logic to handle some better mapping ? {quote} Filtering is a general mechanism. You can exclude/include any library using a regular expression. The feature isn't JBoss AS specific, the defaults are only set to use newer versions of Hibernate/JSF according to Lukáš's comment in https://community.jboss.org/en/tools/blog/2012/01/24/jboss-source-lookup. Since the debugging is intended for the advanced users, using regular expressions shouldn't be a problem. > Filtering libraries in Source Lookup plugin > ------------------------------------------- > > Key: JBIDE-13850 > URL: https://issues.jboss.org/browse/JBIDE-13850 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: maven > Affects Versions: 4.1.0.Alpha1 > Reporter: Snjezana Peco > Assignee: Snjezana Peco > Fix For: 4.1.0.Beta1 > > > jsf 1.2 and hibernate 3 will be excluded by default for the JBoss AS Container -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14350) Search field disappears when Central editor is too small

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14350?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-14350: --------------------------------------- This has been done intentionally. Otherwise, the header text would look ugly. Another solution would be to move the search control to a new row, but, in that case, we would have a lot of empty space in the header of the JBoss Central editor. > Search field disappears when Central editor is too small > -------------------------------------------------------- > > Key: JBIDE-14350 > URL: https://issues.jboss.org/browse/JBIDE-14350 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.1.0.Alpha2 > Reporter: Radim Hopp > Priority: Minor > Fix For: 4.1.0.Beta1 > > Attachments: searchField.png > > > Search field disappears, when Central editor is shrinked to certain width. > Would it be possible either move the search field under buttons and "show on startup" checkbox or define some minimal width. > Thanks > !searchField.png! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 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 April 2013