June 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (TOOLSDOC-654) JBDS-IS 8.0.2: Update supported configurations page

by Misha Ali (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-654?page=com.atlassian.jira.plug... ] Misha Ali reassigned TOOLSDOC-654: ---------------------------------- Assignee: Supriya Bharadwaj (was: Misha Ali) > JBDS-IS 8.0.2: Update supported configurations page > --------------------------------------------------- > > Key: TOOLSDOC-654 > URL: https://issues.jboss.org/browse/TOOLSDOC-654 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Bug > Reporter: Misha Ali > Assignee: Supriya Bharadwaj > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-654) JBDS-IS 8.0.2: Update supported configurations page

by Misha Ali (JIRA)

Misha Ali created TOOLSDOC-654: ---------------------------------- Summary: JBDS-IS 8.0.2: Update supported configurations page Key: TOOLSDOC-654 URL: https://issues.jboss.org/browse/TOOLSDOC-654 Project: Documentation for JBoss Tools and Developer Studio Issue Type: Bug Reporter: Misha Ali Assignee: Misha Ali -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-655) JBDS 9: Update supported configurations page

by Misha Ali (JIRA)

Misha Ali created TOOLSDOC-655: ---------------------------------- Summary: JBDS 9: Update supported configurations page Key: TOOLSDOC-655 URL: https://issues.jboss.org/browse/TOOLSDOC-655 Project: Documentation for JBoss Tools and Developer Studio Issue Type: Bug Reporter: Misha Ali Assignee: Misha Ali -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3456) Resizing JBDS window right after is appears crashes it with GTK3

by Jan Richter (JIRA)

[ https://issues.jboss.org/browse/JBDS-3456?page=com.atlassian.jira.plugin.... ] Jan Richter commented on JBDS-3456: ----------------------------------- So it would seem that Java refuses to give me the log file. I even tried to redirect it using -XX:ErrorFile but there's no such file to be found (and yes I'm talking about the hs_err_whatever aka Java crash log). > Resizing JBDS window right after is appears crashes it with GTK3 > ---------------------------------------------------------------- > > Key: JBDS-3456 > URL: https://issues.jboss.org/browse/JBDS-3456 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: ui/branding > Affects Versions: 9.0.0.Beta1 > Reporter: Jan Richter > Assignee: Snjezana Peco > > If I try to resize/maximize the JBDS window right after launch, it crashes when the window has not finished rendering before the resize. There is no error in the log, just Fedora telling me that the JVM crashed. Running with GTK2 doesn't produce this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TOOLSDOC-653) JBDS 9 Beta1: Generate Docker Article for Beta1 and Summit

by Misha Ali (JIRA)

[ https://issues.jboss.org/browse/TOOLSDOC-653?page=com.atlassian.jira.plug... ] Misha Ali commented on TOOLSDOC-653: ------------------------------------ Created a first draft and asked Xavier to review. https://docs.google.com/a/redhat.com/document/d/1faq5D1L4TgkgKPGa9y6slmfh... > JBDS 9 Beta1: Generate Docker Article for Beta1 and Summit > ---------------------------------------------------------- > > Key: TOOLSDOC-653 > URL: https://issues.jboss.org/browse/TOOLSDOC-653 > Project: Documentation for JBoss Tools and Developer Studio > Issue Type: Bug > Reporter: Misha Ali > Assignee: Misha Ali > > Create a docker article based on what xavier will showcase at summit for Beta1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3440) Consider using TestNG 6.9.4.201505110455 in JBDS 9

by Len DiMaggio (JIRA)

[ https://issues.jboss.org/browse/JBDS-3440?page=com.atlassian.jira.plugin.... ] Len DiMaggio commented on JBDS-3440: ------------------------------------ It seems to be OK - can we add this for beta2? > Consider using TestNG 6.9.4.201505110455 in JBDS 9 > -------------------------------------------------- > > Key: JBDS-3440 > URL: https://issues.jboss.org/browse/JBDS-3440 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: 3rd-party-certification, 3rd-party-dependencies, installer, upstream > Affects Versions: 9.0.0.Beta1 > Reporter: Nick Boldt > Assignee: Len DiMaggio > Fix For: 9.0.0.Beta2 > > > We currently include TestNG 6.8.6.20141201_2240. > But the latest available is 6.9.4.201505110455. > Do we want something newer? > You can try the latest from here: > http://beust.com/eclipse/ > If we decide we want something newer, I can pull a mirror and add it to the Beta1 target platform (JBIDE-19776) already in progress. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19641) Big war deployment via management API gets stuck

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19641?page=com.atlassian.jira.plugi... ] Kabir Khan commented on JBIDE-19641: ------------------------------------ The latest commit on https://github.com/wildfly/wildfly-core/pull/804 contains what I was trying to explain above, with this the test passes http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=56881&buildTyp.... I am trying a run with more normal maven settings as well at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=56887&tab=buil... . I'll take a look at how that went in the morning. > Big war deployment via management API gets stuck > ------------------------------------------------ > > Key: JBIDE-19641 > URL: https://issues.jboss.org/browse/JBIDE-19641 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.0.Alpha2 > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.3.0.Beta2 > > Attachments: stuck-deploy-eap-jstack-osx.log, stuck-deploy-eap-jstack-rhel.log, stuck-deploy-jstack-osx.log, stuck-deploy-jstack-rhel.log > > > When you try to deploy some really big war (~500 MB) to EAP 6.3 via management api, it will not go through. > This is a follow-up of JBIDE-19350 which previously reported this, but Rob eventually used that JIRA to fix a side issue - the stuck operation could not be canceled. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19870) Maven New and Noteworthy for 4.3.0.Beta1

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19870?page=com.atlassian.jira.plugi... ] Fred Bricon closed JBIDE-19870. ------------------------------- Resolution: Done Done > Maven New and Noteworthy for 4.3.0.Beta1 > ---------------------------------------- > > Key: JBIDE-19870 > URL: https://issues.jboss.org/browse/JBIDE-19870 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: maven > Reporter: Max Rydahl Andersen > Assignee: Fred Bricon > Priority: Critical > Fix For: 4.3.0.Beta1 > > > This [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...] contains the search for the specific component(s), to see all, use this [query|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+an...]. > If Maven is not listed here check if there are issues that should be added and add them. > Document the ones relevant for Maven by adding to [whatsnew|https://github.com/jbosstools/jbosstools-website/tree/master/doc...] and submit a pullrequest. > If no news for this component please reject and close this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19641) Big war deployment via management API gets stuck

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19641?page=com.atlassian.jira.plugi... ] Kabir Khan edited comment on JBIDE-19641 at 6/15/15 6:21 PM: ------------------------------------------------------------- The problem is a combination of the client heap size and the copies done by the ByteArrayOutputStream when growing and (with a larger heap) when calling toByteArray() in InputStreamEntry.InMemoryEntry. {code} @Override public synchronized int initialize() throws IOException { final ByteArrayOutputStream os = new ByteArrayOutputStream(); try { StreamUtils.copyStream(original, os); //<-- Fails with small heap } finally { if(autoClose) { StreamUtils.safeClose(original); } } data = os.toByteArray(); //<- Fails with bigger heap return data.length; } {code} The simplest fix is to increase the heap size on the client. When I increase the heap to 4GB my 1GB deployment uploads fine. With a heap of 3GB it fails in the toByteArray() method, with a heap of 2GB it fails earlier in the method, when writing to it and it needs to grow. But that probably isn't the best way. There is also an alternative and unused implementation InputStreamEntry.CachingStreamEntry, which caches the input stream in a temporary file. The protocol seems to need the size, which is why we are doing these initial steps. Switching to that for everything is easy. Switching to it for somethings would require an extra field on InputStreamAttachements or something like that. Alternatively, if the operation attachment InputStreams are passed in as something implementing both InputStream and InputStreamEntry, AbstractModelControllerClient/createStreamEntries() will not create an intermediate InputStreamEntry. Thus an implementation for File, which uses the FileInputStream directly and gets the size from the File (removing the need to copy/cache the whole thing) should do the job. So perhaps a factory method for one of those would be nice to have somewhere? was (Author: kabirkhan): The problem is a combination of the client heap size and the copies done by the ByteArrayOutputStream when growing and (with a larger heap) when calling toByteArray() in InputStreamEntry.InMemoryEntry. {code} @Override public synchronized int initialize() throws IOException { final ByteArrayOutputStream os = new ByteArrayOutputStream(); try { StreamUtils.copyStream(original, os); //<-- Fails with small heap } finally { if(autoClose) { StreamUtils.safeClose(original); } } data = os.toByteArray(); //<- Fails with bigger heap return data.length; } {code} The simplest fix is to increase the heap size on the client. When I increase the heap to 4GB my 1GB deployment uploads fine. With a heap of 3GB it fails in the toByteArray() method, with a heap of 2GB it fails earlier in the method, when writing to it and it needs to grow. But that probably isn't the best way. There is also an alternative and unused implementation InputStreamEntry.CachingStreamEntry, which caches the input stream in a temporary file. The protocol seems to need the size, which is why we are doing these initial steps. Switching to that for everything is easy. Switching to it for somethings would require an extra field on InputStreamAttachements or something like that. Alternatively, if the operation attachment InputStreams are passed in as something implementing both InputStream and InputStreamEntry, AbstractModelControllerClient/createStreamEntries() will not create an additional InputStreamEntry. Thus an implementation for File, which uses the FileInputStream directly and gets the size from the File (removing the need to copy/cache the whole thing) should do the job. So perhaps a factory method for one of those would be nice to have somewhere? > Big war deployment via management API gets stuck > ------------------------------------------------ > > Key: JBIDE-19641 > URL: https://issues.jboss.org/browse/JBIDE-19641 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.0.Alpha2 > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.3.0.Beta2 > > Attachments: stuck-deploy-eap-jstack-osx.log, stuck-deploy-eap-jstack-rhel.log, stuck-deploy-jstack-osx.log, stuck-deploy-jstack-rhel.log > > > When you try to deploy some really big war (~500 MB) to EAP 6.3 via management api, it will not go through. > This is a follow-up of JBIDE-19350 which previously reported this, but Rob eventually used that JIRA to fix a side issue - the stuck operation could not be canceled. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19641) Big war deployment via management API gets stuck

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19641?page=com.atlassian.jira.plugi... ] Kabir Khan edited comment on JBIDE-19641 at 6/15/15 6:20 PM: ------------------------------------------------------------- The problem is a combination of the client heap size and the copies done by the ByteArrayOutputStream when growing and (with a larger heap) when calling toByteArray() in InputStreamEntry.InMemoryEntry. {code} @Override public synchronized int initialize() throws IOException { final ByteArrayOutputStream os = new ByteArrayOutputStream(); try { StreamUtils.copyStream(original, os); //<-- Fails with small heap } finally { if(autoClose) { StreamUtils.safeClose(original); } } data = os.toByteArray(); //<- Fails with bigger heap return data.length; } {code} The simplest fix is to increase the heap size on the client. When I increase the heap to 4GB my 1GB deployment uploads fine. With a heap of 3GB it fails in the toByteArray() method, with a heap of 2GB it fails earlier in the method, when writing to it and it needs to grow. But that probably isn't the best way. There is also an alternative and unused implementation InputStreamEntry.CachingStreamEntry, which caches the input stream in a temporary file. The protocol seems to need the size, which is why we are doing these initial steps. Switching to that for everything is easy. Switching to it for somethings would require an extra field on InputStreamAttachements or something like that. Alternatively, if the operation attachment InputStreams are passed in as something implementing both InputStream and InputStreamEntry, AbstractModelControllerClient/createStreamEntries() will not create an additional InputStreamEntry. Thus an implementation for File, which uses the FileInputStream directly and gets the size from the File (removing the need to copy/cache the whole thing) should do the job. So perhaps a factory method for one of those would be nice to have somewhere? was (Author: kabirkhan): The problem is a combination of the client heap size and the copies done by the ByteArrayOutputStream when growing and (with a larger heap) when calling toByteArray() in InputStreamEntry.InMemoryEntry. {code} @Override public synchronized int initialize() throws IOException { final ByteArrayOutputStream os = new ByteArrayOutputStream(); try { StreamUtils.copyStream(original, os); } finally { if(autoClose) { StreamUtils.safeClose(original); } } data = os.toByteArray(); return data.length; } {code} The simplest fix is to increase the heap size on the client. When I increase the heap to 4GB my 1GB deployment uploads fine. With a heap of 3GB it fails in the toByteArray() method, with a heap of 2GB it fails earlier in the method, when writing to it and it needs to grow. But that probably isn't the best way. There is also an alternative and unused implementation InputStreamEntry.CachingStreamEntry, which caches the input stream in a temporary file. The protocol seems to need the size, which is why we are doing these initial steps. Switching to that for everything is easy. Switching to it for somethings would require an extra field on InputStreamAttachements or something like that. Alternatively, if the operation attachment InputStreams are passed in as something implementing both InputStream and InputStreamEntry, AbstractModelControllerClient/createStreamEntries() will not create an additional InputStreamEntry. Thus an implementation for File, which uses the FileInputStream directly and gets the size from the File (removing the need to copy/cache the whole thing) should do the job. So perhaps a factory method for one of those would be nice to have somewhere? > Big war deployment via management API gets stuck > ------------------------------------------------ > > Key: JBIDE-19641 > URL: https://issues.jboss.org/browse/JBIDE-19641 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.0.Alpha2 > Reporter: Martin Malina > Assignee: Rob Stryker > Fix For: 4.3.0.Beta2 > > Attachments: stuck-deploy-eap-jstack-osx.log, stuck-deploy-eap-jstack-rhel.log, stuck-deploy-jstack-osx.log, stuck-deploy-jstack-rhel.log > > > When you try to deploy some really big war (~500 MB) to EAP 6.3 via management api, it will not go through. > This is a follow-up of JBIDE-19350 which previously reported this, but Rob eventually used that JIRA to fix a side issue - the stuck operation could not be canceled. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

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