April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2438) Drools template : Multiple rows from database map to multiple conditions within the when block of a a single rule

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2438?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-2438: ---------------------------------- Issue Type: Enhancement (was: Bug) > Drools template : Multiple rows from database map to multiple conditions within the when block of a a single rule > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2438 > URL: https://issues.jboss.org/browse/DROOLS-2438 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.6.0.Final > Reporter: Rahul Vanimisetty > Assignee: Mario Fusco > Priority: Blocker > Labels: task > > In a drool template, if i am loading rules from a database, then as per my understanding each row in the database table represents a rule. So a drool template will generate a drl file in the following way : > rule 1 > when > condition(first row of db) > action > rule 2 > condition(2cd row of db) > then > action > etc. > My requirement is to have a dynamic drl generated in the following way : > rule 1 > when > condition 1(1st row of db) > condition 2 (2cd row of db) > condition 3 (3rd row of db) > etc > then > action > end > Please suggest a way to do this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2438) Drools template : Multiple rows from database map to multiple conditions within the when block of a a single rule

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2438?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-2438: ---------------------------------- Priority: Major (was: Blocker) > Drools template : Multiple rows from database map to multiple conditions within the when block of a a single rule > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2438 > URL: https://issues.jboss.org/browse/DROOLS-2438 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.6.0.Final > Reporter: Rahul Vanimisetty > Assignee: Mario Fusco > Labels: task > > In a drool template, if i am loading rules from a database, then as per my understanding each row in the database table represents a rule. So a drool template will generate a drl file in the following way : > rule 1 > when > condition(first row of db) > action > rule 2 > condition(2cd row of db) > then > action > etc. > My requirement is to have a dynamic drl generated in the following way : > rule 1 > when > condition 1(1st row of db) > condition 2 (2cd row of db) > condition 3 (3rd row of db) > etc > then > action > end > Please suggest a way to do this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tibor Digana closed WFLY-9406. ------------------------------ ASM 6.0 appears in wildfly-12.0.0.Final > Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ----------------------------------------------------------------------------- > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Beta1, 12.0.0.Final > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian Extension dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3588) Undertow subsystem should support arbitrary options

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3588?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-3588: --------------------------------- Assignee: (was: Tomaz Cerar) > Undertow subsystem should support arbitrary options > --------------------------------------------------- > > Key: WFLY-3588 > URL: https://issues.jboss.org/browse/WFLY-3588 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > > At the moment all well known options are hard coded in the schema. We should also support dynamic options where the class name is specified. This will allow the use of user defined options. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9597?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9597: --------------------------------- Assignee: (was: Tomaz Cerar) > UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9597 > URL: https://issues.jboss.org/browse/WFLY-9597 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Radoslav Husar > > The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c... > Most likely the same issue is in multiple places. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3090) Make script messages around process restarts consistent

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3090?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-3090: ----------------------------------- Assignee: (was: Tomaz Cerar) > Make script messages around process restarts consistent > ------------------------------------------------------- > > Key: WFCORE-3090 > URL: https://issues.jboss.org/browse/WFCORE-3090 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Brian Stansberry > Priority: Minor > > The message we output when a process is restarted is inconsistent: > standalone.sh "Restarting application server..." > domain.sh "Restarting JBoss..." > standalone.ps1 "Restarting application server..." (from common.ps1) > domain.ps1 "Restarting application server..." (from common.ps1) > standalone.bat nothing > domain.bat nothing > Problems: > 1) domain.ps1 is inaccurate as it's not just an application server being restarted > 2) The bat files are inconsistent with the others > 3) domain.sh's "Restarting JBoss..." is a bit vague and is odd theoretically given that WildFly Core is meant to be usable for all sorts of things that may not be regarded as "JBoss". > Perhaps just KISS "Restarting..." in all cases? If we want to keep "application server" for the standalone.xxx cases then common.ps1's function will need to have a param added, and then we need to decide a meaningful value for that param (empty text being a valid choice.) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-7728) Increased Memory footprint in recent builds

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7728?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-7728. ----------------------------- Resolution: Out of Date > Increased Memory footprint in recent builds > ------------------------------------------- > > Key: WFLY-7728 > URL: https://issues.jboss.org/browse/WFLY-7728 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Critical > > In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended. > Test scenario: > # Start EAP instance. > # Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times. > We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3197) jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3197?page=com.atlassian.jira.plugi... ] Tomaz Cerar reassigned WFCORE-3197: ----------------------------------- Assignee: James Perkins (was: Tomaz Cerar) > jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3197 > URL: https://issues.jboss.org/browse/WFCORE-3197 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: centOs > Reporter: Nuno Godinho de Matos > Assignee: James Perkins > Priority: Trivial > > Hi, I am currently migrating some windows batch scripts associated to an automated create domain/stanadlone process. > One of these scripts, consists on faclitating the user to invoke the jboss cli to run a cli file. > While on windows the script is natrually working. > On linux centOs, the script immediately broke with the error: > {panel} > [johnDoe@localhost bin]$ sh 01_invoke_cli_file_script.sh "file99.sh" > ********************************************************** > SETUP CORE ENV VARIABLES > ********************************************************** > SET_CORE_ENV_VARS_SCRIPT_PATH=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin > CURRENT_WILDFLY_DOMAIN_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/.. > WILDFLY_DOMAINS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../.. > WILDFLY_USER_PROJECTS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../.. > WILDFLY_BASE_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../.. > WILDFLY_BIN_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../../bin > ********************************************************** > INVOKE jboss-cli.bat with script file: "file99.sh" > ********************************************************** > Error: Unable to access jarfile /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/jboss-modules.jar > <----- this some additional informaiton I am printing to make the point > RESOLVED_JBOSS_HOME: /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain > {panel} > What the above panel shows is that the RESOLVED_JBOSS_HOME is not being properly set. > This clearly constrasts with the windows behavior, where my base script can correctly invoke a : > call jboss-cli.bat -f someFilepath > and not break. > The reason for this seems that that while on windows, the script correctly makes no assumption on where the current working directory of the user is. > And only cares about the current location of the jboss-cli.bat script itself. > {panel} > if "%OS%" == "Windows_NT" ( > set "DIRNAME=%~dp0%" <-------- This here is a good approach > ) else ( > set DIRNAME=.\ > ) > {panel} > On linux, the same is not being done: > {panel} > # Setup JBOSS_HOME > RESOLVED_JBOSS_HOME=`cd "$DIRNAME/.."; pwd` <-------- This is not a good approach if dirname is calculated based on the command line DIRNAME=`dirname "$0"` > if [ "x$JBOSS_HOME" = "x" ]; then > # get the full path (without any relative bits) > JBOSS_HOME=$RESOLVED_JBOSS_HOME > else > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME"; pwd` > if [ "$RESOLVED_JBOSS_HOME" != "$SANITIZED_JBOSS_HOME" ]; then > echo "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." > echo "" > fi > fi > export JBOSS_HOME > {panel} > I would suggest that linux scripts shouild cross cuttingly assume nothing about current working directory and do something like: > {code} > #DIRNAME=`dirname "$0"` > DIRNAME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > {code} > Since I do not want to be corrupting my wildfly installation and I want to leave all scripts completely untouched, I will be changing my script invocation from: > {panel} > # source "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > /bin/bash "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > {panel} > Which is not Ideal, since in some scripts I may want to set in my run time environment variables like JAVA_OPTS to override the default ones used on start up of an app server. > So for me, in the ideal case, I would like to be able to use the source command to run any arbitrary script in the /bin folder without my current directory location playing any relevant role. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5793) Allow selective CI builds

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5793?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-5793: --------------------------------- Assignee: Ken Wills (was: Tomaz Cerar) > Allow selective CI builds > ------------------------- > > Key: WFLY-5793 > URL: https://issues.jboss.org/browse/WFLY-5793 > Project: WildFly > Issue Type: Enhancement > Reporter: Ryan Emerson > Assignee: Ken Wills > Priority: Optional > > Currently the testsuite is ran against all PRs regardless of which files are being changed. This is waste of energy/resources when commits only contain changes that do not effect code (e.g. when updating README.md). > A possible solution would be for a blacklist to be created, which lists the file types which can be safely ignored by CI when a PR only contains changes to files of the listed file types. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9477) Cannot create two hosts with unspecified default web module in Undertow

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9477?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9477: --------------------------------- Assignee: (was: Tomaz Cerar) > Cannot create two hosts with unspecified default web module in Undertow > ----------------------------------------------------------------------- > > Key: WFLY-9477 > URL: https://issues.jboss.org/browse/WFLY-9477 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.Final > Reporter: Tomaz Cerar > Priority: Minor > > As a user, I cannot create two hosts with unspecified default web module. Currently the default-web-module is checked only for uniqueness and by default there is defined ROOT.war, which by default doesn't exist. Current behavior is that in case of non existing module defined by default-web-module, when accessing the root context ('/'), the content defined as part of welcome-file handler is provided. > As a user I should not be forced to put random values to avoid duplicity check, when I don't want to have set default-web-module. As such the default-web-module should have undefined default which could be checked and avoided failures due duplicates as there are in reality none. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018