December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5899) Expression like BigDecimal_type_property = BigDecimal_type_property.divide(BigDecimal_value) causes a build failure in executable model.

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5899?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5899: --------------------------------- Sprint: 2020 Week 49-51 (from Nov 30) > Expression like BigDecimal_type_property = BigDecimal_type_property.divide(BigDecimal_value) causes a build failure in executable model. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5899 > URL: https://issues.redhat.com/browse/DROOLS-5899 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: support > > Compiling a rule like (*1) which is described in MVEL dialect and uses an expression like _BigDecimal_type_property_ = _BigDecimal_type_property_.divide(_BigDecimal_value_), for example (*1-1), with executable rule models enabled, an error like (*2) occurs. > This issue occurs in the case of using the other basic operation add, subtract and multiply as well as divide. > (*1) > {noformat} > package com.example.reproducer > import com.example.reproducer.Bus > import java.math.BigDecimal > dialect "mvel" > rule "bus3d" > when > $bus : Bus() > then > $bus.weight = $bus.weight.divide(BigDecimal.valueOf(1000)); ..... (*1-1) > System.out.println("***** " + $bus + ", weight = " + $bus.weight); > end > {noformat} > $bus.weight is a BigDecimal type property. > (*2) > {noformat} > [ERROR] Unable to build KieBaseModel:rules > CompilationProblemErrorResult: org.drools.mvelcompiler.MvelCompilerException: RHS doesn't have a type > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFWIP-367) WildFly can stuck for a while when trying to connect an unavailable Kafka socket and is terminated

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFWIP-367?page=com.atlassian.jira.plugin... ] Kabir Khan commented on WFWIP-367: ---------------------------------- [~cescoffi] FYI - I have been seeing something like this too but never got around to isolating it. I will see if it can be reproduced with e.g. the SmallRye RM Kafka quickstart later this week > WildFly can stuck for a while when trying to connect an unavailable Kafka socket and is terminated > -------------------------------------------------------------------------------------------------- > > Key: WFWIP-367 > URL: https://issues.redhat.com/browse/WFWIP-367 > Project: WildFly WIP > Issue Type: Bug > Reporter: Jan Stourac > Assignee: Kabir Khan > Priority: Major > Attachments: helloworld-sources.jar, helloworld.war > > > It looks WildFly can stuck for a while with the newly introduced MP Reactive Messaging implementation. If one deploy a deployment that utilizes 'smallrye-kafka' connector it then repeatedly tries to connect against Kafka instance. If that instance is not available on configured socket, then undeploy operation of the app stucks for a while. Similar thing happens for shutdown operation of the server via regular 'ctrl+C' signal. > Based on the discussion, this may be an issue that needs to be addressed on SmallRye side as there may be some timeout reached before Kafka connector stops listening. > From user point of view - both these operations are not 'graceful' as such - in both cases user expects that undeploy and shutdown should be performed immediately. Thinking about it, I think that even in case of a graceful shutdown, since these are just an attempts for a connection, there is still no need to linger with server shutdown. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-12610) Provide a proper :recover management operation for transactions

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-12610?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-12610: ------------------------------------ We are hitting another issue related to recovery when a bootable jar is used. To enable recovery, WildFly server must be restarted with another set of system properties for the transaction manager to properly recover transactions. However Bootable Jar does not support server restart. Ideally, the tx subsystem would expose a :recover operation with all required configuration passed as attributes to be able to perform recovery without requiring a server restart. > Provide a proper :recover management operation for transactions > --------------------------------------------------------------- > > Key: WFLY-12610 > URL: https://issues.redhat.com/browse/WFLY-12610 > Project: WildFly > Issue Type: Enhancement > Components: Transactions > Affects Versions: 18.0.0.Beta1 > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > Based on the operator work at https://github.com/wildfly/wildfly-operator it seems that the operations required by the admin to perform recovery are quite complex. > It seems that the customer must to: > 1. make sure that tx recovery listener is enabled in the tx subsystem > 1.a read the correct port from the socket binding, don't forget to also read the portOffset and take it into account > 2. connect to this tx-recovery-port opened by the server and send a SCAN command > 3. read the Pod log with a regexp "ERROR.*Periodic Recovery" > 3.a don't forget to timestamp the logs > 4. read recursively all tx logs to check that there are no in-doubts tx > Oh and if you want to configure the tx recovery process, please add the correct system properties om.arjuna.ats.arjuna.common.Recovery* > This creates a lot of complexities for the customer (and the operator code) that should be encapsulated by the transactions subsystem. > Tthe subsystem should provide a :recover management operation > that deals with connecting with Narayana (no need to open a socket since Narayana is IN-VM) and perform the scan / logs checking / etc. and return the useful information to the user (the in-doubt TX) > Likewise, any recovery configuration should be handled by the transactions and not through System properties. > [1] https://github.com/wildfly/wildfly-operator/blob/master/pkg/controller/wi... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14227) Upgrade jboss-jaxb-api_2.3_spec to 2.0.1.Final

by Ricardo Martin Camarero (Jira)

Ricardo Martin Camarero created WFLY-14227: ---------------------------------------------- Summary: Upgrade jboss-jaxb-api_2.3_spec to 2.0.1.Final Key: WFLY-14227 URL: https://issues.redhat.com/browse/WFLY-14227 Project: WildFly Issue Type: Component Upgrade Components: XML Frameworks Affects Versions: 21.0.1.Final Reporter: Ricardo Martin Camarero Assignee: Ricardo Martin Camarero Upgrade to pick up WFLY-13968. Diff: https://github.com/jboss/jboss-jakarta-jaxb-api_spec/compare/2.0.0.Final.... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14218) Non-HA standalone*.xml variant uses wrong distributable-web feature group

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14218?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14218: -------------------------------- Summary: Non-HA standalone*.xml variant uses wrong distributable-web feature group (was: Non-HA standalone*.xml variants uses wrong distributable-web feature group) > Non-HA standalone*.xml variant uses wrong distributable-web feature group > ------------------------------------------------------------------------- > > Key: WFLY-14218 > URL: https://issues.redhat.com/browse/WFLY-14218 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 21.0.1.Final, 22.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Non-HA configurations should use the distributable-web-local feature group, not distributable-web. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14210) The jaxrs subsystem had new attributes added without a schema bump

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-14210?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-14210: --------------------------------- Release Notes Text: In WildFly 19 new attributes were add to the subsystem. The 2.0.0 subsystem model version has been used since WildFly 11. The transformers have been setup to reject all attributes on the 2.0.0 version. Because WildFly 19, 20 and 21 also use the 2.0.0 subsystem model version a system property org.wildfly.jaxrs.unsupported.bypass.2.0.0.transformer was introduced to bypass the 2.0.0 transformers. This should be carefully used. Affects: Release Notes > The jaxrs subsystem had new attributes added without a schema bump > ------------------------------------------------------------------ > > Key: WFLY-14210 > URL: https://issues.redhat.com/browse/WFLY-14210 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 22.0.0.Beta1 > > > WFLY-12298 introduced attributes to the jaxrs subsystem. While the schema was bumped, the model version was not. Because of this there is no reliable way to correctly use transformers from WildFly 19 -> WildFly 11. Note that WildFly 11 was the first version to bump to model version 2.0.0 and WildFly 19 kept the same model version, but added the attributes. > JBoss EAP should not be impacted as no releases contain, with the exception of JBoss EAP CD19 and JBoss EAP CD20 Tech Preview releases, the attributes. > We should set the transformers up to reject the attributes for model version 2.0.0 and 1.0.0. An unsupported system property should be introduced to allow the rejection of attributes for 2.0.0 on WildFly mixed domain environments. While this is an unlikely scenario it would be nice to have. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14218) Non-HA standalone*.xml variants uses wrong distributable-web feature group

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14218?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14218: -------------------------------- Description: Non-HA configurations should use the distributable-web-local feature group, not distributable-web. (was: Since standalone-microprofile.xml is non-ha, it should use the distributable-web-local feature group, not distributable-web.) > Non-HA standalone*.xml variants uses wrong distributable-web feature group > -------------------------------------------------------------------------- > > Key: WFLY-14218 > URL: https://issues.redhat.com/browse/WFLY-14218 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 21.0.1.Final, 22.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Non-HA configurations should use the distributable-web-local feature group, not distributable-web. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14218) Non-HA standalone*.xml variants uses wrong distributable-web feature group

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14218?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14218: -------------------------------- Summary: Non-HA standalone*.xml variants uses wrong distributable-web feature group (was: standalone-microprofile.xml uses wrong distributable-web feature group variant) > Non-HA standalone*.xml variants uses wrong distributable-web feature group > -------------------------------------------------------------------------- > > Key: WFLY-14218 > URL: https://issues.redhat.com/browse/WFLY-14218 > Project: WildFly > Issue Type: Bug > Components: Build System > Affects Versions: 21.0.1.Final, 22.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Since standalone-microprofile.xml is non-ha, it should use the distributable-web-local feature group, not distributable-web. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14221) FaceletsViewMappingTestCase fails in -Dts.ee9 tests

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-14221?page=com.atlassian.jira.plugi... ] Farah Juma commented on WFLY-14221: ----------------------------------- Thanks, [~smarlow]! {{FaceletsViewMappingsTestCase}} is a new test that was recently added in this PR: https://github.com/wildfly/wildfly/pull/13772 However, this test depends on the fix for WFLY-13792 that was included in the recent Mojarra 2.3.14.SP02 release. I've now incorporated recent fixes from our 2.3.14.SP branch into the 3.0.0.SP branch, released 3.0.0.SP03, and submitted a component upgrade PR to update the Mojarra version in the EE9 feature-pack: https://github.com/wildfly/wildfly/pull/13824 With this component upgrade, {{FaceletsViewMappingsTestCase}} passes. > FaceletsViewMappingTestCase fails in -Dts.ee9 tests > --------------------------------------------------- > > Key: WFLY-14221 > URL: https://issues.redhat.com/browse/WFLY-14221 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Brian Stansberry > Assignee: Farah Juma > Priority: Major > Fix For: 22.0.0.Beta1 > > > Beginning Dec 7 FaceletsViewMappingTestCase began failing in the nightly CI job that runs the -Dts.ee9 profile: > https://ci.wildfly.org/viewType.html?buildTypeId=WF_WildflyPreviewNightly > My guess is this is related to the update of the JSF API fork that went in around that time. > [~smarlow] [~parsharma] [~fjuma] FYI -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14226) Upgrade Mojarra to 3.0.0.SP03 in the EE9 feature pack

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-14226?page=com.atlassian.jira.plugi... ] Farah Juma updated WFLY-14226: ------------------------------ Description: This upgrade incorporates fixes from the Mojarra 2.3.14.SP branch. Mojarra 3.0.0.SP03 is still based off the upstream 3.0.0-RC5 release since the 3.0.0 version is still not usable yet since it adds a dependency on Hibernate Validator 7.0.0.Final which is still not in any publicly available repo yet. > Upgrade Mojarra to 3.0.0.SP03 in the EE9 feature pack > ----------------------------------------------------- > > Key: WFLY-14226 > URL: https://issues.redhat.com/browse/WFLY-14226 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > > This upgrade incorporates fixes from the Mojarra 2.3.14.SP branch. > Mojarra 3.0.0.SP03 is still based off the upstream 3.0.0-RC5 release since the 3.0.0 version is still not usable yet since it adds a dependency on Hibernate Validator 7.0.0.Final which is still not in any publicly available repo yet. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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

jboss-jira December 2020