September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4470) DMN DT Analysis check allowedValues from imported ItemDef

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-4470?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-4470: ----------------------------------- Labels: good-first-issue (was: ) > DMN DT Analysis check allowedValues from imported ItemDef > --------------------------------------------------------- > > Key: DROOLS-4470 > URL: https://issues.jboss.org/browse/DROOLS-4470 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: good-first-issue > > The domain analysis restricts the domain in case of allowedValues defined in the ItemDef. To be checked the domain restriction is properly working when the DT column domain is actually defined coming from an imported itemdef. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4383) DMN DT exec model does not cascade down allowedValues to input/outputValues of DT

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-4383?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-4383: ----------------------------------- Description: See [DROOLS-4379] test case a. To be investigated: there is a slight diff behavior when using interpreted Vs exec-model, as the allowedValues does not seems to be cascaded down from the ItemDefinition to the input/outputValues of the Decision Table (was: See [DROOLS-4379] test case a. To be investigated.) > DMN DT exec model does not cascade down allowedValues to input/outputValues of DT > --------------------------------------------------------------------------------- > > Key: DROOLS-4383 > URL: https://issues.jboss.org/browse/DROOLS-4383 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: good-first-issue > > See [DROOLS-4379] test case a. To be investigated: there is a slight diff behavior when using interpreted Vs exec-model, as the allowedValues does not seems to be cascaded down from the ItemDefinition to the input/outputValues of the Decision Table -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-207) UX: Force removal of Operator upon delete - do not hang due to finalizers

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFWIP-207?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka commented on WFWIP-207: ---------------------------------------- I created an issue on this at the `wildfly/wildfly-operator` repository - https://github.com/wildfly/wildfly-operator/issues/82 > UX: Force removal of Operator upon delete - do not hang due to finalizers > ------------------------------------------------------------------------- > > Key: WFWIP-207 > URL: https://issues.jboss.org/browse/WFWIP-207 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Petr Kremensky > Assignee: Ondrej Chaloupka > Priority: Blocker > Labels: operator > > We run yet into another use case where finalizers prevent users from deleting the project - the delete operation hangs. > pods: > {noformat} > $ oc get all > NAME READY STATUS RESTARTS AGE > pod/simple-jaxrs-operator-0 0/1 ImagePullBackOff 0 9m11s > pod/simple-jaxrs-operator-1 0/1 ImagePullBackOff 0 9m11s > pod/wildfly-operator-686846d6fb-db9sj 1/1 Running > $ oc delete wildflyserver simple-jaxrs-operator > wildflyserver.wildfly.org "simple-jaxrs-operator" deleted > ... hangs forever > {noformat} > operator log: > {noformat} > {"level":"info","ts":1569308322.2926116,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator"} > {"level":"info","ts":1569308322.2927597,"logger":"controller_wildflyserver","msg":"WildflyServer is marked for deletion. Waiting for finalizers to clean the workspace","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator"} > {"level":"info","ts":1569308322.2929516,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator","Pod Name":"simple-jaxrs-operator-0","IP Address":"10.128.0.227","Pod State":"SCALING_DOWN_RECOVERY_INVESTIGATION","Pod Phase":"Pending"} > {"level":"info","ts":1569308322.2931426,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator","Pod Name":"simple-jaxrs-operator-1","IP Address":"10.128.0.226","Pod State":"SCALING_DOWN_RECOVERY_INVESTIGATION","Pod Phase":"Pending"} > {"level":"error","ts":1569308322.294659,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"pkremens-namespace/simple-jaxrs-operator","error":"Finalizer processing: failed transaction recovery for WildflyServer pkremens-namespace:simple-jaxrs-operator name Error: Found 2 errors:\n [[Pod 'simple-jaxrs-operator-0' / 'simple-jaxrs-operator' is in pending phase Pending. It will be hopefully started in a while. Transaction recovery needs the pod being fully started to be capable to mark it as clean for the scale down.]], [[Pod 'simple-jaxrs-operator-1' / 'simple-jaxrs-operator' is in pending phase Pending. It will be hopefully started in a while. Transaction recovery needs the pod being fully started to be capable to mark it as clean for the scale down.]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."} > {noformat} > This is a call between safety vs. usability, but we believe that these issues (hanging delete command due to EAP7-1192) could be a serious usability problem for users. > *actual* > * scale down can require manual user interaction forced by finalizers > * delete can hang, requiring manual user interaction (delete deployment object, remove finalizer from operator CR, run delete again) > *expected* > * scale down can require manual user interaction forced by finalizers > * delete should never hang, it should be treated like a pulling a plug (rm -rf), in case users needs to make s graceful shutdown, he make a proper scale down to 0 prior the project deletion - this should be properly documented -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2769) callback methods for: before/after invoke BKM/DS

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-2769?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-2769: ----------------------------------- Description: {quote}As part of another feature, I would like to create callback methods for both "before/after invoke BKM/DS", so that we can report on actual execution of BKMs and Decision Services. But this is a conversation for another day.{quote} Ref https://github.com/kiegroup/drools/pull/1986#discussion_r204029977 Augment Listener and implement callbacks when invoking BKM and Decision Service(s) was: {quote}As part of another feature, I would like to create callback methods for both "before/after invoke BKM/DS", so that we can report on actual execution of BKMs and Decision Services. But this is a conversation for another day.{quote} Ref https://github.com/kiegroup/drools/pull/1986#discussion_r204029977 > callback methods for: before/after invoke BKM/DS > ------------------------------------------------ > > Key: DROOLS-2769 > URL: https://issues.jboss.org/browse/DROOLS-2769 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > Labels: good-first-issue > > {quote}As part of another feature, I would like to create callback methods for both "before/after invoke BKM/DS", so that we can report on actual execution of BKMs and Decision Services. But this is a conversation for another day.{quote} > Ref https://github.com/kiegroup/drools/pull/1986#discussion_r204029977 > Augment Listener and implement callbacks when invoking BKM and Decision Service(s) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3280) DMNRuntime API for evaluateByID/Name to error if empty array

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3280?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-3280: ----------------------------------- Description: there is already some null-check for the public API parameters. However if passing an empty array (e.g. in the varargs) is still semantically wrong when calling these public API method (e.g. evaluate by ID, without passing any IDs). Augment to extend proper checks to support end-user using public API > DMNRuntime API for evaluateByID/Name to error if empty array > ------------------------------------------------------------ > > Key: DROOLS-3280 > URL: https://issues.jboss.org/browse/DROOLS-3280 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: good-first-issue > > there is already some null-check for the public API parameters. However if passing an empty array (e.g. in the varargs) is still semantically wrong when calling these public API method (e.g. evaluate by ID, without passing any IDs). Augment to extend proper checks to support end-user using public API -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4513) s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails

by Karel Suta (Jira)

[ https://issues.jboss.org/browse/DROOLS-4513?page=com.atlassian.jira.plugi... ] Karel Suta commented on DROOLS-4513: ------------------------------------ [~filippe.spolti] Can you please check your PR? It seems to break some tests. > s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-4513 > URL: https://issues.jboss.org/browse/DROOLS-4513 > Project: Drools > Issue Type: Bug > Components: build, kie server > Affects Versions: 7.14.0.Final, 7.18.0.Final, 7.24.0.Final > Environment: OpenShift 3.11 with rhdm72-prod-immutable-kieserver.yaml/rhdm73-prod-immutable-kieserver.yaml > Reporter: Hiroko Miura > Assignee: Filippe Spolti > Priority: Major > Labels: support > Attachments: ruleTest.zip > > > If multiple ksession are defined in kmodule.xml and Event Lister is set more than one ksession, s2i build fails at KieServerContainerVerifier with the following error. > {noformat} > [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT > java.lang.RuntimeException: Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT > at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186) > at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:172) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:65) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:53) > at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:40) > at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:119) > at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:101) > at org.jboss.modules.Module.run(Module.java:352) > at org.jboss.modules.Module.run(Module.java:320) > at org.jboss.modules.Main.main(Main.java:593) > [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - com.redhat.gss:ruleTest:1.0.0-SNAPSHOT not verified. > ERROR Aborting due to error code 1 from kie server container verification > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3948: ---------------------------------------- Assignee: Brian Stansberry I'll do something along the lines of the last one -- add an instance of a new class as a DU attachment and have the DUPs use it to coordinate. The subdeployment DeploymentStructureDescriptorParser instances don't proceed until the root has, and then none of them proceed into ManifestDependencyProcessor until they've all completed ManifestClassPathProcessor. And some thread safety stuff for AttachmentList. > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.jboss.org/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Assignee: Brian Stansberry > Priority: Major > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ] Scott Marlow commented on WFCORE-3948: -------------------------------------- Assuming that ManifestClassPathProcessor, ManifestDependencyProcessor and DeploymentStructureDescriptorParser are running during the STRUCTURE phase, because they have to. If we introduced a STRUCTURE2 phase, we could expect ADDITIONAL_MODULES writing is done during the (first) STRUCTURE phase and by the time we reach the second STRUCTURE2 phase, it is safe to read the ADDITIONAL_MODULES. At least this could be a goal, that we could see if we could reach. Another high level idea, since the ManifestClassPathProcessor.deploy() is already synchronized, if ManifestDependencyProcessor.deploy() and DeploymentStructureDescriptorParser.deploy() were made to also synchronize on the same object, we would slow deployment time but I think wouldn't see the ConcurrentModificationException any more. Or slightly better performing idea, could be to use a ReadWriteLock, where ManifestClassPathProcessor, ManifestDependencyProcessor and DeploymentStructureDescriptorParser code that reads ADDITIONAL_MODULES, waits on a shared read lock and writes to ADDITIONAL_MODULES waits on an exclusive write lock. > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.jboss.org/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Priority: Major > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4679) Update the mock-server-netty dep; specify the logback dep

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4679: ---------------------------------------- Summary: Update the mock-server-netty dep; specify the logback dep Key: WFCORE-4679 URL: https://issues.jboss.org/browse/WFCORE-4679 Project: WildFly Core Issue Type: Task Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Some of our tests use mock-server-netty 5.4.1. Full WF uses 5.6.1. Moving to 5.6.1 is good because: 1) It's good to be aligned with full, just because. 2) 5.4.1 brings in some transitive deps that we get vulnerability warnings about, which is annoying to deal with just for a test dep. However, moving to 5.6.1 means there's no longer a mock-server-netty dep pulling in ch.qos.logback:logback-classic and logback-core. And it seems a couple tests in testsuite/embedded require at least one of those deps, as I guess they are testing how embedded works when logback is the embedding app's logging impl. So the fix there is to explicitly declare the logback dep. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-142) Support java.util.function.Supplier as a parameter to logs and bundles

by James Perkins (Jira)

[ https://issues.jboss.org/browse/LOGTOOL-142?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-142: --------------------------------------- This would have to likely be supported in JBoss Logging as well. Having be logic in generated code could increase the memory footprint quite a bit if suppliers are excessively used. Though it's something to consider so that this won't be blocked by a logging fix. > Support java.util.function.Supplier as a parameter to logs and bundles > ---------------------------------------------------------------------- > > Key: LOGTOOL-142 > URL: https://issues.jboss.org/browse/LOGTOOL-142 > Project: Log Tool > Issue Type: Enhancement > Affects Versions: 2.2.0.Final > Reporter: Daniel Siviter > Priority: Major > > Similar to JDK logging that supports deferred logging using {{java.util.function.Supplier}}, allow for JBoss logging but for each parameter within a log and bundle. > e.g. > {code} > @LogMessage > @Message("I'm going to log something computationally expensive: %s") > void expensive(Supplier<String> value); > {code} > Which could then be used as: > {code} > LogInterface.LOG.expensive(this::toExpensiveFormattedString); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

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 September 2019