September 2013 - jbosstools-issues

[JBoss JIRA] (JBTIS-161) Should the JBTIS 4.1 target platform include SpringIDE 3.3 instead of 3.2?

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-161?page=com.atlassian.jira.plugin.... ] Paul Leacu updated JBTIS-161: ----------------------------- Assignee: Paul Leacu > Should the JBTIS 4.1 target platform include SpringIDE 3.3 instead of 3.2? > -------------------------------------------------------------------------- > > Key: JBTIS-161 > URL: https://issues.jboss.org/browse/JBTIS-161 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: target-platform > Affects Versions: 4.1.2 > Reporter: Nick Boldt > Assignee: Paul Leacu > > The version of SpringIDE vetted by QE to be included in JBDS 7 Central is Spring IDE 3.3 [1]. > [1] http://download.jboss.org/jbosstools/updates/requirements/springide/3.3.0... > However, as reported in http://fusesource.com/issues/browse/ECLIPSE-955 Fuse currently depends on Spring IDE 3.2 [2] > [2] https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... > This disconnect may cause problems when co-installing SpringIDE 3.3 from JBDS Central and Fuse (which will bring in SpringIDE 3.2 jars). > Therefore, should Central, JBTIS TP 4.1, and Fuse all use the same version of Spring IDE, namely 3.3 instead of 3.2 and 3.3? -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2746) On a Full Publish LiveReload refreshes the browser before the application is fully restarted

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBDS-2746?page=com.atlassian.jira.plugin.... ] Xavier Coulon closed JBDS-2746. ------------------------------- Assignee: Xavier Coulon Resolution: Duplicate Issue This issue is a duplicate of JBIDE-15403 and it will be fixed in JBIDE. > On a Full Publish LiveReload refreshes the browser before the application is fully restarted > -------------------------------------------------------------------------------------------- > > Key: JBDS-2746 > URL: https://issues.jboss.org/browse/JBDS-2746 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: build > Reporter: Pete Muir > Assignee: Xavier Coulon > > I can't quite tell if the same problem exists for Incremental Publish. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15403) On a Full Publish LiveReload refreshes the browser before the application is fully restarted

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15403?page=com.atlassian.jira.plugi... ] Xavier Coulon updated JBIDE-15403: ---------------------------------- Summary: On a Full Publish LiveReload refreshes the browser before the application is fully restarted (was: CLONE - On a Full Publish LiveReload refreshes the browser before the application is fully restarted) Assignee: Xavier Coulon Affects Version/s: 4.1.0.Final > On a Full Publish LiveReload refreshes the browser before the application is fully restarted > -------------------------------------------------------------------------------------------- > > Key: JBIDE-15403 > URL: https://issues.jboss.org/browse/JBIDE-15403 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: livereload > Affects Versions: 4.1.0.Final > Reporter: Xavier Coulon > Assignee: Xavier Coulon > > I can't quite tell if the same problem exists for Incremental Publish. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2757) Remove java 6 requirement of EAP from installer

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-2757?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-2757: ------------------------------------------- the target release was not set to 7.1.0 thus bugs weren't auto-acked. now its set to 7.1.0 and its pm autoacked. > Remove java 6 requirement of EAP from installer > ----------------------------------------------- > > Key: JBDS-2757 > URL: https://issues.jboss.org/browse/JBDS-2757 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 7.1.0.Alpha1 > Environment: OS X Mountain Lion > Reporter: Martin Malina > Attachments: ins-step-4.png, ins-step-5.png > > > There are two strings I would like removed from the installer: > Step 4 > Please note that JBoss EAP 6 requires Java 6 or higher. > !ins-step-4.png! > Step 5 > (Java 6 is required to run JBoss EAP 6) > !ins-step-5.png! > I think this was added when we still supported running of JBDS with Java 5, but now that JBDS needs Java 6 I think it's not needed to point this out explicitly. > Also, in Step 4 there's this: > JBoss Developer Studio works with Java 6 and has been tested with OpenJDK, Oracle and Apple JDK. > - Here I would add Java 7 to the mix - we test that too. > And last, EAP should be Red Hat JBoss Enterprise Application Platform (in Step 5). -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2757) Remove java 6 requirement of EAP from installer

by CDW Engine (JIRA)

[ https://issues.jboss.org/browse/JBDS-2757?page=com.atlassian.jira.plugin.... ] CDW Engine updated JBDS-2757: ----------------------------- CDW devel_ack: ? CDW pm_ack: + (was: ?) CDW qa_ack: ? > Remove java 6 requirement of EAP from installer > ----------------------------------------------- > > Key: JBDS-2757 > URL: https://issues.jboss.org/browse/JBDS-2757 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 7.1.0.Alpha1 > Environment: OS X Mountain Lion > Reporter: Martin Malina > Attachments: ins-step-4.png, ins-step-5.png > > > There are two strings I would like removed from the installer: > Step 4 > Please note that JBoss EAP 6 requires Java 6 or higher. > !ins-step-4.png! > Step 5 > (Java 6 is required to run JBoss EAP 6) > !ins-step-5.png! > I think this was added when we still supported running of JBDS with Java 5, but now that JBDS needs Java 6 I think it's not needed to point this out explicitly. > Also, in Step 4 there's this: > JBoss Developer Studio works with Java 6 and has been tested with OpenJDK, Oracle and Apple JDK. > - Here I would add Java 7 to the mix - we test that too. > And last, EAP should be Red Hat JBoss Enterprise Application Platform (in Step 5). -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBDS-2757) Remove java 6 requirement of EAP from installer

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-2757?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen updated JBDS-2757: -------------------------------------- Target Release: 7.1.0.GA (was: 3.0.2.GA) > Remove java 6 requirement of EAP from installer > ----------------------------------------------- > > Key: JBDS-2757 > URL: https://issues.jboss.org/browse/JBDS-2757 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: installer > Affects Versions: 7.1.0.Alpha1 > Environment: OS X Mountain Lion > Reporter: Martin Malina > Attachments: ins-step-4.png, ins-step-5.png > > > There are two strings I would like removed from the installer: > Step 4 > Please note that JBoss EAP 6 requires Java 6 or higher. > !ins-step-4.png! > Step 5 > (Java 6 is required to run JBoss EAP 6) > !ins-step-5.png! > I think this was added when we still supported running of JBDS with Java 5, but now that JBDS needs Java 6 I think it's not needed to point this out explicitly. > Also, in Step 4 there's this: > JBoss Developer Studio works with Java 6 and has been tested with OpenJDK, Oracle and Apple JDK. > - Here I would add Java 7 to the mix - we test that too. > And last, EAP should be Red Hat JBoss Enterprise Application Platform (in Step 5). -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15392) Add api in server needed for source lookup

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15392?page=com.atlassian.jira.plugi... ] Snjezana Peco edited comment on JBIDE-15392 at 9/10/13 7:02 AM: ---------------------------------------------------------------- {quote} Wouldn't it be the simplest to be able to create a class that provides all these default settings for the server type based on result from the beanloaders ? {quote} The API Rob created within this PR (RuntimeJarUtility) works this way. The only thing he would need to add is using a default configuration for JBoss AS < 7.0. {quote} And seriously - why can't sourcelookup just know about the runtime and if it does not know about it simply just return all jars ? then all this custom knowledge in sourcelookup goes away ? {quote} A source lookup container knows only a home directory because it can be used for non JBoss servers as well as for servers that aren't defined in Eclipse. This API should provide all jars from JBoss servers (excluding application's jars) based on a home directory. was (Author: snjeza): {quote} Wouldn't it be the simplest to be able to create a class that provides all these default settings for the server type based on result from the beanloaders ? {quote} The API Rob created within this PR (RuntimeJarUtility) works this way. The only thing he would need to add is using a default configuration for JBoss AS < 7.0. {quote} And seriously - why can't sourcelookup just know about the runtime and if it does not know about it simply just return all jars ? then all this custom knowledge in sourcelookup goes away ? {quoute} A source lookup container knows only a home directory because it can be used for non JBoss servers as well as for servers that aren't defined in Eclipse. This API should provide all jars from JBoss servers (excluding application's jars) based on a home directory. > Add api in server needed for source lookup > ------------------------------------------ > > Key: JBIDE-15392 > URL: https://issues.jboss.org/browse/JBIDE-15392 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: maven, server > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Fix For: 4.2.0.Alpha1 > > > As uncovered in https://github.com/jbosstools/jbosstools-central/pull/128/files#L5L120 we got a problem with source lookup code always having to play catchup with server changes. > We need to define a stable api that can be used here. > lets outline what api is actually needed and then subjiras for the specifics. > For me it looks like server lookup needs a few things: > 0. know exact version of server > 1. know the file structure of a certain server > 2. get dir or directories that contain jar that is the "runtime" > My guess is that #2 might just be sufficient for source code lookup. > Any comments ? -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-6010) Tooling Support for Byteman Rule Injection

by Masao Kunii (JIRA)

[ https://issues.jboss.org/browse/JBIDE-6010?page=com.atlassian.jira.plugin... ] Masao Kunii commented on JBIDE-6010: ------------------------------------ Hi, Andrew and Max, Thank you for your comment. Yes, we can provide our sources on Github. But I have to do some procedure in my company, I'm afraid. It may take about 2 weeks. Then I will make repository on Github. Please wait until then. bq. btw. have you compared/tried it with the work done in BYTEMAN-29 which is at https://github.com/adinn/byteman-eclipse-prototype ? Yes, I have looked it. It has similar implementation of rule editor compare to ours, but some codes have not implemented yet. Our tool has more features, so I think it is easier to merge byteman-eclipse-prototype with ours if byteman-eclipse-prototype has unique feature. > Tooling Support for Byteman Rule Injection > ------------------------------------------ > > Key: JBIDE-6010 > URL: https://issues.jboss.org/browse/JBIDE-6010 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: z - Legacy - integration > Reporter: Andrew Dinn > Labels: integration > Fix For: LATER > > > It would be nice to have support for Byteman in these areas: > 1) editor support for creation and modification of Byteman rule files > 2) debugger support for detection of successful or ailed rule injection at runtime > 3) debugger support for stepping through injected rule code > the byteman agent already runs a listener which provides the info required for ii. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-108) ESBHandler possibly does not set name

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBTIS-108?page=com.atlassian.jira.plugin.... ] Rob Stryker closed JBTIS-108. ----------------------------- There is no way to trigger this bug, as it only occurred during a refactor of runtimes. So in builds previous to the refactor, the bug was not visible because the code's workflow was slightly different and the bug was never hit. After the refactor, the bug was also never hit, because the issue was fixed immediately. It is possible that there is one or two nightly builds where the bug is present, but, this was a very very long time ago, and I sincerely doubt we can find those nightly builds. In short, I believe strongly the bug is fixed. > ESBHandler possibly does not set name > ------------------------------------- > > Key: JBTIS-108 > URL: https://issues.jboss.org/browse/JBTIS-108 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ESB > Affects Versions: 4.1.0.Beta1 > Reporter: Rob Stryker > Assignee: Brian Fitzpatrick > Fix For: 4.1.0.Beta1 > > > The line which sets a name for the esb runtime object is inside an if-statement, which means it may NOT be set at all. > This is a bug ;) -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15392) Add api in server needed for source lookup

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15392?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-15392: --------------------------------------- {quote} Wouldn't it be the simplest to be able to create a class that provides all these default settings for the server type based on result from the beanloaders ? {quote} The API Rob created within this PR (RuntimeJarUtility) works this way. The only thing he would need to add is using a default configuration for JBoss AS < 7.0. {quote} And seriously - why can't sourcelookup just know about the runtime and if it does not know about it simply just return all jars ? then all this custom knowledge in sourcelookup goes away ? {quoute} A source lookup container knows only a home directory because it can be used for non JBoss servers as well as for servers that aren't defined in Eclipse. This API should provide all jars from JBoss servers (excluding application's jars) based on a home directory. > Add api in server needed for source lookup > ------------------------------------------ > > Key: JBIDE-15392 > URL: https://issues.jboss.org/browse/JBIDE-15392 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: maven, server > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Fix For: 4.2.0.Alpha1 > > > As uncovered in https://github.com/jbosstools/jbosstools-central/pull/128/files#L5L120 we got a problem with source lookup code always having to play catchup with server changes. > We need to define a stable api that can be used here. > lets outline what api is actually needed and then subjiras for the specifics. > For me it looks like server lookup needs a few things: > 0. know exact version of server > 1. know the file structure of a certain server > 2. get dir or directories that contain jar that is the "runtime" > My guess is that #2 might just be sufficient for source code lookup. > Any comments ? -- 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, 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 2013