October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1336) Globals variables are not present in Globals Data View

by Tomas David (JIRA)

Tomas David created DROOLS-1336: ----------------------------------- Summary: Globals variables are not present in Globals Data View Key: DROOLS-1336 URL: https://issues.jboss.org/browse/DROOLS-1336 Project: Drools Issue Type: Bug Components: eclipse plugin Reporter: Tomas David Assignee: Robert (Bob) Brodt Attachments: globals.png I just create this issue since this is problem which is present for very long time but I can't find corresponding issue in Bugzilla or Jira. If global variables are used in drools project and it is debugged. No global variables are present in Global Data View. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1336) Globals variables are not present in Globals Data View

by Tomas David (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1336?page=com.atlassian.jira.plugi... ] Tomas David updated DROOLS-1336: -------------------------------- Steps to Reproduce: # Create default Drools project with HelloWorld rule file # Edit Sample.drl file, add lines: global String stringVar global Object objectVar global List listVar # Edit DroolsTest.java file, add lines: kSession.setGlobal("listVar", java.util.Arrays.asList(1, 2, 3)); kSession.setGlobal("objectVar", new Object()); kSession.setGlobal("stringVar", "testStringValue"); # Debug the project # Open Global Data View was: # Create default Drools project with HelloWorld rule file # Edit Sample.drl file, add lines: {{global String stringVar global Object objectVar global List listVar}} # Edit DroolsTest.java file, add lines: {{kSession.setGlobal("listVar", java.util.Arrays.asList(1, 2, 3)); kSession.setGlobal("objectVar", new Object()); kSession.setGlobal("stringVar", "testStringValue");}} # Debug the project # Open Global Data View > Globals variables are not present in Globals Data View > ------------------------------------------------------ > > Key: DROOLS-1336 > URL: https://issues.jboss.org/browse/DROOLS-1336 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Reporter: Tomas David > Assignee: Robert (Bob) Brodt > Labels: reported-by-qe > Attachments: globals.png > > > I just create this issue since this is problem which is present for very long time but I can't find > corresponding issue in Bugzilla or Jira. > If global variables are used in drools project and it is debugged. No global variables are present in Global Data View. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-773) ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-773: ------------------------------------------------ Petr Jurak <pjurak(a)redhat.com> changed the Status of [bug 1231070|https://bugzilla.redhat.com/show_bug.cgi?id=1231070] from ASSIGNED to POST > ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor > -------------------------------------------------------------------------------------------- > > Key: WFCORE-773 > URL: https://issues.jboss.org/browse/WFCORE-773 > Project: WildFly Core > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Petr Jurak > > BoundedQueueThreadPool does not support zero length queue setup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1878: ---------------------------------------------- QE contact has already been contacted. Waiting for his feedback. > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1878: ----------------------------------------- Fix Version/s: 3.0.0.Alpha10 Priority: Blocker (was: Major) > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1878: ---------------------------------------------- I am proposing to use the '*' character and make it clear in documentation tha tit is not a pattern but that it identifies "All disabled deployments". > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1878: ------------------------------------------ I recommend starting with pinging the QE Tester on the feature to get quick input on your plans. Then comment on EAP7-515, update the analysis doc, the code and the community docs. > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Jean-Francois Denise edited comment on WFCORE-1878 at 10/19/16 9:26 AM: ------------------------------------------------------------------------ Yes, that is the plan. I am wandering what is the impact on the original RFE: https://issues.jboss.org/browse/EAP7-515 Should I move it back to Analysis dev? Should we keep it as it is and simply change the public community documentation? was (Author: jdenise): Yes, that is the plan. I am wandering what is the impact on the original RFE: https://issues.jboss.org/browse/EAP7-515 Should I move it back to Analysis dev? Should be keep it as it and simply change the public community documentation? > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1878: ---------------------------------------------- Yes, that is the plan. I am wandering what is the impact on the original RFE: https://issues.jboss.org/browse/EAP7-515 Should I move it back to Analysis dev? Should be keep it as it and simply change the public community documentation? > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1878: ------------------------------------------ IIRC <ALL> is new and has never been in a .Final release, so if there is any concern about it let's change it now. You can increase the priority to Critical or Blocker and set a Fix Version if that's your plan. That will help ensure it doesn't get missed. > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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

jboss-jira October 2016