January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5955) KieScanner not properly updating model assets (classes) on incremental updates

by B Brown (Jira)

[ https://issues.redhat.com/browse/DROOLS-5955?page=com.atlassian.jira.plug... ] B Brown updated DROOLS-5955: ---------------------------- Attachment: TestScannerUpdate-1.0.0-SNAPSHOT.jar > KieScanner not properly updating model assets (classes) on incremental updates > ------------------------------------------------------------------------------ > > Key: DROOLS-5955 > URL: https://issues.redhat.com/browse/DROOLS-5955 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.48.0.Final > Reporter: B Brown > Assignee: Mario Fusco > Priority: Major > Attachments: LogFile.txt, RunTest.java, TestScannerUpdate-1.0.0-SNAPSHOT.jar > > > KieScanner is not correctly applying incremental kjar updates to KieContainer when those updates include changes to "Model" assets authored in Business Central. > Adding a new field to a model in business central, then updating a rule to reference that value will work the first time. If you repeat this again, adding another new field and new reference in a rule, after updating the KieContainer using KieScanner, executing fireAllRules on a new session will fail with an exception, claiming it cannot find the setter method for the new attribute. > It is expected that the KieScanner should be able to take new kjars produced from BC and consistently update KieContainers with their updates. There is no workaround for this. Please refer to the "Steps to Reproduce". I've also attached the final kjar that caused the error, the main method that ran the test as well as the log file. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5955) KieScanner not properly updating model assets (classes) on incremental updates

by B Brown (Jira)

[ https://issues.redhat.com/browse/DROOLS-5955?page=com.atlassian.jira.plug... ] B Brown updated DROOLS-5955: ---------------------------- Attachment: LogFile.txt > KieScanner not properly updating model assets (classes) on incremental updates > ------------------------------------------------------------------------------ > > Key: DROOLS-5955 > URL: https://issues.redhat.com/browse/DROOLS-5955 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.48.0.Final > Reporter: B Brown > Assignee: Mario Fusco > Priority: Major > Attachments: LogFile.txt, RunTest.java, TestScannerUpdate-1.0.0-SNAPSHOT.jar > > > KieScanner is not correctly applying incremental kjar updates to KieContainer when those updates include changes to "Model" assets authored in Business Central. > Adding a new field to a model in business central, then updating a rule to reference that value will work the first time. If you repeat this again, adding another new field and new reference in a rule, after updating the KieContainer using KieScanner, executing fireAllRules on a new session will fail with an exception, claiming it cannot find the setter method for the new attribute. > It is expected that the KieScanner should be able to take new kjars produced from BC and consistently update KieContainers with their updates. There is no workaround for this. Please refer to the "Steps to Reproduce". I've also attached the final kjar that caused the error, the main method that ran the test as well as the log file. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5955) KieScanner not properly updating model assets (classes) on incremental updates

by B Brown (Jira)

B Brown created DROOLS-5955: ------------------------------- Summary: KieScanner not properly updating model assets (classes) on incremental updates Key: DROOLS-5955 URL: https://issues.redhat.com/browse/DROOLS-5955 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.48.0.Final Reporter: B Brown Assignee: Mario Fusco KieScanner is not correctly applying incremental kjar updates to KieContainer when those updates include changes to "Model" assets authored in Business Central. Adding a new field to a model in business central, then updating a rule to reference that value will work the first time. If you repeat this again, adding another new field and new reference in a rule, after updating the KieContainer using KieScanner, executing fireAllRules on a new session will fail with an exception, claiming it cannot find the setter method for the new attribute. It is expected that the KieScanner should be able to take new kjars produced from BC and consistently update KieContainers with their updates. There is no workaround for this. Please refer to the "Steps to Reproduce". I've also attached the final kjar that caused the error, the main method that ran the test as well as the log file. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14310) JPASubsystemAdd uses non-standard attribute value resolution

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14310: --------------------------------------- Summary: JPASubsystemAdd uses non-standard attribute value resolution Key: WFLY-14310 URL: https://issues.redhat.com/browse/WFLY-14310 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Brian Stansberry Assignee: Brian Stansberry JPASubsystemAdd processes a couple attributes in non-standard ways, not using AttributeDefinition.resolveModelAttribute. The code handles the primary things resolveModelAttribute handles (default values and basic expression resolution) but it doesn't handle the full set of expression resolution capability WildFly supports. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14295) ProtoStream marshallers for java.util.* classes should not use packed encoding

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14295?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14295: -------------------------------- Summary: ProtoStream marshallers for java.util.* classes should not use packed encoding (was: ProtoStream collection/map marshallers should not use packed encoding) > ProtoStream marshallers for java.util.* classes should not use packed encoding > ------------------------------------------------------------------------------ > > Key: WFLY-14295 > URL: https://issues.redhat.com/browse/WFLY-14295 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 22.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The protobuf specification indicates that packed encoding is only valid for varint and fixed byte values. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14295) ProtoStream collection/map marshallers should not use packed encoding

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14295?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14295: -------------------------------- Description: The protobuf specification indicates that packed encoding is only valid for varint and fixed byte values. was:The protobuf specification indicates that packed encoding is only valid for varint and fixed byte values. > ProtoStream collection/map marshallers should not use packed encoding > --------------------------------------------------------------------- > > Key: WFLY-14295 > URL: https://issues.redhat.com/browse/WFLY-14295 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 22.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The protobuf specification indicates that packed encoding is only valid for varint and fixed byte values. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14186) Update netty.io to 4.1.58

by Boris Unckel (Jira)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14186) Update netty.io to 4.1.58

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14186?page=com.atlassian.jira.plugi... ] Boris Unckel updated WFLY-14186: -------------------------------- Summary: Update netty.io to 4.1.58 (was: Update netty.io to 4.1.54) > Update netty.io to 4.1.58 > ------------------------- > > Key: WFLY-14186 > URL: https://issues.redhat.com/browse/WFLY-14186 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering, JMS > Reporter: Boris Unckel > Assignee: Paul Ferraro > Priority: Major > > Update [netty.io 4.1.54|https://mvnrepository.com/artifact/io.netty/netty-all/4.1.54.Final] > Release Notes > [https://netty.io/news/2020/11/11/4-1-54-Final.html] > [https://netty.io/news/2020/10/13/4-1-53-Final.html] > [https://netty.io/news/2020/09/08/4-1-52-Final.html] -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13940) SingletonDeploymentJBossAllTestCase fails frequently in CI

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13940?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFLY-13940: ------------------------------------- [~brian.stansberry] Yeah - I've noticed as well. It's not exactly clear to me why this test in particular fails often, while the SingletonDeploymentDescriptorTestCase does not - as these tests are functionally identical (the only difference is the location of configuration). I suspect it is related to the order in which this test runs relative to others - and whether or not there are artifacts from previous tests that are somehow interfering with this one. I'll see about stabilizing this in the WF23 cycle. > SingletonDeploymentJBossAllTestCase fails frequently in CI > ---------------------------------------------------------- > > Key: WFLY-13940 > URL: https://issues.redhat.com/browse/WFLY-13940 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 21.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14052) EE 9 jms/core20/jmscontexttopictests#getMetaDataTest tests expects JMS version 3.0 but is seeing 2.0

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14052?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-14052: ------------------------------------ Labels: EE9 (was: ) > EE 9 jms/core20/jmscontexttopictests#getMetaDataTest tests expects JMS version 3.0 but is seeing 2.0 > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-14052 > URL: https://issues.redhat.com/browse/WFLY-14052 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Scott Marlow > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: EE9 > > {quote} > \u001b[0m\u001b[0m13:52:58,657 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Error: incorrect JMSVersion=2.0 > \u001b[0m\u001b[0m13:52:58,657 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Error: incorrect JMSMajorVersion=2 > \u001b[0m\u001b[0m13:52:58,657 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: getMetaDataTest failed > \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Test case throws exception: getMetaDataTest failed > \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: Exception at: > \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) 11-06-2020 13:52:58: ERROR: com.sun.ts.lib.harness.EETest$Fault: getMetaDataTest failed > \u001b[0m\u001b[0m13:52:58,658 INFO [stdout] (Thread-161) at com.sun.ts.tests.jms.core20.jmscontexttopictests.Client.getMetaDataTest(Client.java:475) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at java.lang.reflect.Method.invoke(Method.java:498) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.EETest.run(EETest.java:596) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:40) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.lib.harness.EETest.run(EETest.java:285) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > \u001b[0m\u001b[0m13:52:58,659 INFO [stdout] (Thread-161) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > \u001b[0m\u001b[0m13:52:58,660 INFO [stdout] (Thread-161) at java.lang.reflect.Method.invoke(Method.java:498) > \u001b[0m\u001b[0m13:52:58,660 INFO [stdout] (Thread-161) at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:99) > \u001b[0m\u001b[0m13:52:58,660 INFO [stdout] (Thread-161) at java.lang.Thread.run(Thread.java:748) > {quote} > [jakarta.jms.ConnectionMetaData.classConnectionMetaData|https://jakarta.ee/specifications/messaging/3.0/apidocs/] is returning Jakarta EE 8 versions instead of Jakarta EE 9.0 versions -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 January 2021