September 2015 - jbosstools-issues

[JBoss JIRA] (JBIDE-20765) The JBoss Central connectorDescriptor description field text should be displayed with some type of auto-formatting if it's too large for the label space.

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20765?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-20765: ----------------------------------- Priority: Minor (was: Major) > The JBoss Central connectorDescriptor description field text should be displayed with some type of auto-formatting if it's too large for the label space. > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-20765 > URL: https://issues.jboss.org/browse/JBIDE-20765 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: discovery > Affects Versions: 4.3.0.CR1 > Reporter: Paul Leacu > Assignee: Mickael Istria > Priority: Minor > Fix For: 4.3.1.Final > > > The JBoss Central connectorDescriptor description field should be displayed with some type of auto-formatting if it's too large for the label space. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20767) Create tests for the Hbm2DDLExporter facade implementations

by Koen Aers (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20767?page=com.atlassian.jira.plugi... ] Koen Aers resolved JBIDE-20767. ------------------------------- Resolution: Done > Create tests for the Hbm2DDLExporter facade implementations > ----------------------------------------------------------- > > Key: JBIDE-20767 > URL: https://issues.jboss.org/browse/JBIDE-20767 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: hibernate > Reporter: Koen Aers > Assignee: Koen Aers > Fix For: 4.4.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20765) The JBoss Central connectorDescriptor description field text should be displayed with some type of auto-formatting if it's too large for the label space.

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20765?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-20765: ---------------------------------------- I'm suggesting usage of a CLabel, that will put "Text beginning...Text end" with ... in the middle of the text if it's too large, and using a tooltip to show full description content. > The JBoss Central connectorDescriptor description field text should be displayed with some type of auto-formatting if it's too large for the label space. > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-20765 > URL: https://issues.jboss.org/browse/JBIDE-20765 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: discovery > Affects Versions: 4.3.0.CR1 > Reporter: Paul Leacu > Assignee: Mickael Istria > Fix For: 4.3.1.Final > > > The JBoss Central connectorDescriptor description field should be displayed with some type of auto-formatting if it's too large for the label space. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20767) Create tests for the Hbm2DDLExporter facade implementations

by Koen Aers (JIRA)

Koen Aers created JBIDE-20767: --------------------------------- Summary: Create tests for the Hbm2DDLExporter facade implementations Key: JBIDE-20767 URL: https://issues.jboss.org/browse/JBIDE-20767 Project: Tools (JBoss Tools) Issue Type: Task Components: hibernate Reporter: Koen Aers Assignee: Koen Aers Fix For: 4.4.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-676) Review Evaluate OpenShiftv3 with JBDS

by Misha Ali (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-676?page=com.atlassian.jira.plug... ] Misha Ali commented on TOOLSDOC-676: ------------------------------------ Updated here: https://access.redhat.com/articles/1609003 And created a PR for this change in JBT docs here: https://github.com/jbosstools/jbosstools-website/pull/490 If these are now OK, we can set this to resolved. What do you think, [~mlabuda]? > Review Evaluate OpenShiftv3 with JBDS > ------------------------------------- > > Key: TOOLSDOC-676 > URL: https://issues.jboss.org/browse/TOOLSDOC-676 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Sub-task > Components: General documentation issues > Reporter: Misha Ali > Assignee: Misha Ali > Attachments: sceenshot_egit.png > > > Available for review here with details for an environment used to test: > https://docs.google.com/document/d/1UppL95LhLL1jzbBFoQetVL-qZB6oTVK54Xktr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20750) Slow Memory Leak in JSF tools

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20750?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-20750 at 9/22/15 11:38 PM: ------------------------------------------------------------------------- I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only. When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject. It turns out that if objects are released for garbage collection in few large structures (like the entire KbProject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb. was (Author: scabanovich): I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only. When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject. It turns out that if objects are released for garbage collection in few large structures (like the entire KbObject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb. > Slow Memory Leak in JSF tools > ----------------------------- > > Key: JBIDE-20750 > URL: https://issues.jboss.org/browse/JBIDE-20750 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsf > Affects Versions: 4.3.0.CR1 > Reporter: Denis Golovin > Assignee: Viacheslav Kabanovich > Priority: Critical > Fix For: 4.3.1.Final, 4.4.0.Alpha1 > > Attachments: .log, heap-snapshot1.png, heap-snapshot2.png, mem-usage.png, oom1.png, oom2.png > > > Opening then closing jsf projects slowly consumes heap memory, whish leads to slowing down overal performance and eventually to GC overhead limit exceeded exceptions. > Attached screenshot list: > 1. GC overhead limit exceeded error [^oom1.png]; > 2. Heap Memory Usage timeline [^mem-usage.png]; > 3. Heap Memory Objects filtered for "org.jboss.tools" [^heap-snapshot2.png]; > 4. Heap Memory Objects none filtered [^heap-snapshot1.png]; > 5. OOM Dialog [^oom2.png]ж > 6. [^.log] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20750) Slow Memory Leak in JSF tools

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20750?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich edited comment on JBIDE-20750 at 9/22/15 11:38 PM: ------------------------------------------------------------------------- I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only. When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject. It turns out that if objects are released for garbage collection in few large structures (like the entire KbProject), JVM may 'tolerate' them as long as it approaches the memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb. was (Author: scabanovich): I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only. When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject. It turns out that if objects are released for garbage collection in few large structures (like the entire KbProject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb. > Slow Memory Leak in JSF tools > ----------------------------- > > Key: JBIDE-20750 > URL: https://issues.jboss.org/browse/JBIDE-20750 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsf > Affects Versions: 4.3.0.CR1 > Reporter: Denis Golovin > Assignee: Viacheslav Kabanovich > Priority: Critical > Fix For: 4.3.1.Final, 4.4.0.Alpha1 > > Attachments: .log, heap-snapshot1.png, heap-snapshot2.png, mem-usage.png, oom1.png, oom2.png > > > Opening then closing jsf projects slowly consumes heap memory, whish leads to slowing down overal performance and eventually to GC overhead limit exceeded exceptions. > Attached screenshot list: > 1. GC overhead limit exceeded error [^oom1.png]; > 2. Heap Memory Usage timeline [^mem-usage.png]; > 3. Heap Memory Objects filtered for "org.jboss.tools" [^heap-snapshot2.png]; > 4. Heap Memory Objects none filtered [^heap-snapshot1.png]; > 5. OOM Dialog [^oom2.png]ж > 6. [^.log] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20750) Slow Memory Leak in JSF tools

by Viacheslav Kabanovich (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20750?page=com.atlassian.jira.plugi... ] Viacheslav Kabanovich commented on JBIDE-20750: ----------------------------------------------- I have found one reference to KbProject object that is not released, so the memory leak exists and technically can be resolved by removing this reference only. When testing results, I compared this solution with the other where also method dispose() was implemented on KbObject. It turns out that if objects are released for garbage collection in few large structures (like the entire KbObject), JVM may 'tolerate' them as long as it approaches memory limit. On the other hand, if large structures are dissected into 'atoms', JVM may invoke garbage collector even if these objects take in total just a couple of Mb. > Slow Memory Leak in JSF tools > ----------------------------- > > Key: JBIDE-20750 > URL: https://issues.jboss.org/browse/JBIDE-20750 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsf > Affects Versions: 4.3.0.CR1 > Reporter: Denis Golovin > Assignee: Viacheslav Kabanovich > Priority: Critical > Fix For: 4.3.1.Final, 4.4.0.Alpha1 > > Attachments: .log, heap-snapshot1.png, heap-snapshot2.png, mem-usage.png, oom1.png, oom2.png > > > Opening then closing jsf projects slowly consumes heap memory, whish leads to slowing down overal performance and eventually to GC overhead limit exceeded exceptions. > Attached screenshot list: > 1. GC overhead limit exceeded error [^oom1.png]; > 2. Heap Memory Usage timeline [^mem-usage.png]; > 3. Heap Memory Objects filtered for "org.jboss.tools" [^heap-snapshot2.png]; > 4. Heap Memory Objects none filtered [^heap-snapshot1.png]; > 5. OOM Dialog [^oom2.png]ж > 6. [^.log] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-682) JBDS 9 CR1: Release Notes

by Misha Ali (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-682?page=com.atlassian.jira.plug... ] Misha Ali resolved TOOLSDOC-682. -------------------------------- Resolution: Done Resolving this since all content except the N&N was acked by martin and the N&N is taken from the upstream so it should be ok. > JBDS 9 CR1: Release Notes > ------------------------- > > Key: TOOLSDOC-682 > URL: https://issues.jboss.org/browse/TOOLSDOC-682 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Bug > Components: Release Notes > Affects Versions: 4.3.0.Final > Reporter: Misha Ali > Assignee: Misha Ali > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20760) docker feature not included in Marketplace entry for JBoss Tools

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20760?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-20760: --------------------------------------- +1 to live with original feature with a disabled update site, it is not that bad as it would be enabled. > docker feature not included in Marketplace entry for JBoss Tools > ---------------------------------------------------------------- > > Key: JBIDE-20760 > URL: https://issues.jboss.org/browse/JBIDE-20760 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: marketplace > Affects Versions: 4.3.0.CR1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Labels: xtriage > Fix For: 4.3.0.Final > > Attachments: 20760.png > > > Because we removed the docker feature and replaced it with the docker plugins in order to avoid the odious problem of a disabled update site appearing in Eclipse's list of Available Update Sites, we no longer have a way to provide the docker tooling via our Marketplace entry. > Solution: > 1. Stop caring if there's an extra *disabled* update site in Eclipse when we install JBT (there's a disabled Mylyn one there too, plus 4 enabled ones for Mars, Mylyn, Eclipse, and WTP, so what's one more?). > 2. Use the Docker Tooling feature in JBT's CoreTools category & on the Marketplace entry (as we did for Beta2). > Then, for JBDS, we continue to just use the plugins and include them in the com.jboss.devstudio.core.feature so they're installed OOTB via the BYOE / Core feature (and also via Marketplace). > Sound good? > Alternative solutions: > a. Create a new feature wrapper, just to contain the docker plugins > b. Update some JBT plugins to depend on the docker plugins so they get installed along with the existing JBT plugin > c. do nothing -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 September 2015