July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4556) Upgrade jboss-remoting to 5.0.13.Final

by Teresa Miyar Gil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4556?page=com.atlassian.jira.plugi... ] Teresa Miyar Gil reassigned WFCORE-4556: ---------------------------------------- Assignee: Flavia Rainone (was: Jeff Mesnil) > Upgrade jboss-remoting to 5.0.13.Final > -------------------------------------- > > Key: WFCORE-4556 > URL: https://issues.jboss.org/browse/WFCORE-4556 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Teresa Miyar Gil > Assignee: Flavia Rainone > Priority: Major > Labels: downstream_dependency > > Upgrade jboss-remoting to 5.0.12.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4557) The read http-upgrade-enabled attribute operation acquires the write lock unnecessarily

by Yeray Borges (Jira)

Yeray Borges created WFCORE-4557: ------------------------------------ Summary: The read http-upgrade-enabled attribute operation acquires the write lock unnecessarily Key: WFCORE-4557 URL: https://issues.jboss.org/browse/WFCORE-4557 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Yeray Borges Assignee: Yeray Borges When we are reading the http-upgrade-enabled, the model is read acquiring the write lock. That could make the operation block until the write lock is released by any other underlying operation that previously has acquired it. The read handler only reads the value and put it in the response, so taking the write lock here is unnecessary. This issue affects the ongoing work in WFCORE-4283, there, we could have servers starting with the write lock taken, so it negatively affects to any reading of this attribute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4556) Upgrade jboss-remoting to 5.0.13.Final

by Teresa Miyar Gil (Jira)

Teresa Miyar Gil created WFCORE-4556: ---------------------------------------- Summary: Upgrade jboss-remoting to 5.0.13.Final Key: WFCORE-4556 URL: https://issues.jboss.org/browse/WFCORE-4556 Project: WildFly Core Issue Type: Component Upgrade Reporter: Teresa Miyar Gil Assignee: Jeff Mesnil Upgrade jboss-remoting to 5.0.12.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1840) Strong type defined credential store in client schema

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1840: ------------------------------------- Summary: Strong type defined credential store in client schema Key: ELY-1840 URL: https://issues.jboss.org/browse/ELY-1840 Project: WildFly Elytron Issue Type: Feature Request Components: Authentication Client, Credential Store Reporter: Darran Lofthouse We are trying to use more strongly typed self describing configuration however the credential store still depends on configuration properties - this is fine for custom stores but our implementation needs to be easy to configure. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4285) Slow build due to inefficient EnumServiceImpl.doValidation() call

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4285?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-4285: ----------------------------------- Story Points: 3 Sprint: 2019 Week 26-28 > Slow build due to inefficient EnumServiceImpl.doValidation() call > ----------------------------------------------------------------- > > Key: DROOLS-4285 > URL: https://issues.jboss.org/browse/DROOLS-4285 > Project: Drools > Issue Type: Bug > Components: Enumerations Editor > Affects Versions: 7.23.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools, support > > In a live environment with ~1300 assets, the project build takes ~20 minutes when invoked in decision-central. > Using a debugger, I observe that one execution of KieModuleMetaInfo.unmarshallMetaInfos() takes 20 seconds. It's called from EnumServiceImpl.validate(). > {noformat} > at org.drools.core.rule.KieModuleMetaInfo.unmarshallMetaInfos(KieModuleMetaInfo.java:49) > at org.kie.scanner.KieModuleMetaDataImpl.indexMetaInfo(KieModuleMetaDataImpl.java:251) > at org.kie.scanner.KieModuleMetaDataImpl.indexKieModule(KieModuleMetaDataImpl.java:100) > at org.kie.scanner.KieModuleMetaDataImpl.<init>(KieModuleMetaDataImpl.java:85) > at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:60) > at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:48) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl.doValidation(EnumServiceImpl.java:272) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl.validate(EnumServiceImpl.java:263) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl.validate(EnumServiceImpl.java:253) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl$Proxy$_$$_WeldClientProxy.validate(Unknown Source) > at org.kie.workbench.common.services.backend.builder.core.Builder.build(Builder.java:238) > {noformat} > However, {{EnumServiceImpl.validate()}} is repeatedly called in a loop in Builder.build(). So all ".enumeration" files call this method (this project has 18 .enumeration files). It results in 6 min in my env. > Probably the unmarshalled KieModuleMetaInfo can be cached? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4285) Slow build due to inefficient EnumServiceImpl.doValidation() call

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4285?page=com.atlassian.jira.plugi... ] Michael Anstis moved RHDM-1005 to DROOLS-4285: ---------------------------------------------- Project: Drools (was: Red Hat Decision Manager) Key: DROOLS-4285 (was: RHDM-1005) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Docs QE Status: NEW Component/s: Enumerations Editor (was: Decision Central) Affects Version/s: 7.23.0.Final (was: 7.3.1.GA) QE Status: NEW > Slow build due to inefficient EnumServiceImpl.doValidation() call > ----------------------------------------------------------------- > > Key: DROOLS-4285 > URL: https://issues.jboss.org/browse/DROOLS-4285 > Project: Drools > Issue Type: Bug > Components: Enumerations Editor > Affects Versions: 7.23.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools, support > > In a live environment with ~1300 assets, the project build takes ~20 minutes when invoked in decision-central. > Using a debugger, I observe that one execution of KieModuleMetaInfo.unmarshallMetaInfos() takes 20 seconds. It's called from EnumServiceImpl.validate(). > {noformat} > at org.drools.core.rule.KieModuleMetaInfo.unmarshallMetaInfos(KieModuleMetaInfo.java:49) > at org.kie.scanner.KieModuleMetaDataImpl.indexMetaInfo(KieModuleMetaDataImpl.java:251) > at org.kie.scanner.KieModuleMetaDataImpl.indexKieModule(KieModuleMetaDataImpl.java:100) > at org.kie.scanner.KieModuleMetaDataImpl.<init>(KieModuleMetaDataImpl.java:85) > at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:60) > at org.kie.scanner.KieModuleMetaData$Factory.newKieModuleMetaData(KieModuleMetaData.java:48) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl.doValidation(EnumServiceImpl.java:272) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl.validate(EnumServiceImpl.java:263) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl.validate(EnumServiceImpl.java:253) > at org.drools.workbench.screens.enums.backend.server.EnumServiceImpl$Proxy$_$$_WeldClientProxy.validate(Unknown Source) > at org.kie.workbench.common.services.backend.builder.core.Builder.build(Builder.java:238) > {noformat} > However, {{EnumServiceImpl.validate()}} is repeatedly called in a loop in Builder.build(). So all ".enumeration" files call this method (this project has 18 .enumeration files). It results in 6 min in my env. > Probably the unmarshalled KieModuleMetaInfo can be cached? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1839) The schemas are in the wrong location

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1839: ------------------------------------- Summary: The schemas are in the wrong location Key: ELY-1839 URL: https://issues.jboss.org/browse/ELY-1839 Project: WildFly Elytron Issue Type: Bug Reporter: Darran Lofthouse Fix For: 1.10.0.CR3 The schemas are currently located in "./tests/base/src/main/resources/schema" these may be needed for testing purposes but these should be in a module somewhere exposed as public API. This could also potentially be a new module that just contains schemas if needed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4258) DMN UX - overlay information about a single scenario run

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-4258?page=com.atlassian.jira.plugi... ] Klara Kufova updated DROOLS-4258: --------------------------------- Sprint: (was: 2019 Week 26-28) > DMN UX - overlay information about a single scenario run > -------------------------------------------------------- > > Key: DROOLS-4258 > URL: https://issues.jboss.org/browse/DROOLS-4258 > Project: Drools > Issue Type: Story > Components: DMN Editor > Affects Versions: 7.24.0.Final > Reporter: Daniele Zonca > Assignee: Tao Zhu > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam, drools-tools > > Related to https://issues.jboss.org/browse/DROOLS-3731 > This task will cover this use case: > - user creates a DMN model > - user creates a Test Scenario with some scenarios > - user executes the Test Scenario > - user open Coverage Report > - user wants to analyze the execution of a *single scenario* in the DMN model > - user clicks on "a link" related to the scenario to analyze > - user lands on DMN editor with overlay information about decision executed, decision failed and for each decision the possibility see actual and expected value (from the scenario) and to open an executed decision table to see which row has been evaluated -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-163) WildFlyServerStatus is not present in operator description

by Petr Kremensky (Jira)

[ https://issues.jboss.org/browse/WFWIP-163?page=com.atlassian.jira.plugin.... ] Petr Kremensky updated WFWIP-163: --------------------------------- Environment: openshift v3.11.82 operator 0.2.0 quay.io/wildfly/wildfly-centos7:17.0 was: openshift v3.11.82 operator 0.2.0 > WildFlyServerStatus is not present in operator description > ----------------------------------------------------------- > > Key: WFWIP-163 > URL: https://issues.jboss.org/browse/WFWIP-163 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Environment: openshift v3.11.82 > operator 0.2.0 > quay.io/wildfly/wildfly-centos7:17.0 > Reporter: Petr Kremensky > Assignee: Jeff Mesnil > Priority: Blocker > > According to the [operator api documentation|https://github.com/wildfly/wildfly-operator/blob/master/doc...], the deployment pods status should be pard of operator description, but I failed to find such on OPC. > Install the wildfly operator on OCP as described by [wildfly-operator - openshift|https://github.com/wildfly/wildfly-operator#openshift] section. > *steps to reproduce* > {noformat} > $ cat << EOF > simple-jaxrs-wildfly.yaml > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > name: simple-jaxrs-wildfly > spec: > applicationImage: "pkremens/simple-jaxrs-wildfly" > size: 2 > EOF > $ oc apply -f simple-jaxrs-wildfly.yaml > $ oc expose service/simple-jaxrs-wildfly-loadbalancer > # verify that application is accessible > $ ROUTE=$(oc get route.route.openshift.io/simple-jaxrs-wildfly-loadbalancer --template='{{ .spec.host }}') > $ curl $ROUTE/ping > pong > $ oc describe wildflyserver simple-jaxrs-wildfly > Name: simple-jaxrs-wildfly > Namespace: myproject > Labels: <none> > Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"wildfly.org/v1alpha1","kind":"WildFlyServer","metadata":{"annotations":{},"name":"simple-jaxrs-wildfly","namespace":"myproject"},"spec":... > API Version: wildfly.org/v1alpha1 > Kind: WildFlyServer > Metadata: > Creation Timestamp: 2019-07-02T13:11:58Z > Generation: 1 > Resource Version: 4318 > Self Link: /apis/wildfly.org/v1alpha1/namespaces/myproject/wildflyservers/simple-jaxrs-wildfly > UID: f8eb76bf-9cca-11e9-b8ee-52540043aed8 > Spec: > Application Image: pkremens/simple-jaxrs-wildfly > Size: 2 > Events: <none> > {noformat} > Operator status is not part of the object. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4257) DMN UX - overlay information about an entire simulation execution

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-4257?page=com.atlassian.jira.plugi... ] Klara Kufova updated DROOLS-4257: --------------------------------- Sprint: (was: 2019 Week 26-28) > DMN UX - overlay information about an entire simulation execution > ----------------------------------------------------------------- > > Key: DROOLS-4257 > URL: https://issues.jboss.org/browse/DROOLS-4257 > Project: Drools > Issue Type: Story > Components: DMN Editor > Affects Versions: 7.24.0.Final > Reporter: Daniele Zonca > Assignee: Tao Zhu > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam, drools-tools > > Related to https://issues.jboss.org/browse/DROOLS-3731 > This task will cover this use case: > - user creates a DMN model > - user creates a Test Scenario with some scenarios > - user executes the Test Scenario > - user open Coverage Report > - user wants to analyze coverage information of the *whole* simulation > - user clicks on "a link" near global coverage information > - user lands on DMN editor with overlay information about number of time each decision has been executed, number of time each decision succeed/fail (maybe with different colors?) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 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

jboss-jira July 2019