[Red Hat JIRA] (WFLY-14004) AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.8 & JDK 11.0.9
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14004?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFLY-14004:
----------------------------------
Summary: AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.8 & JDK 11.0.9 (was: AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.9)
> AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.8 & JDK 11.0.9
> -----------------------------------------------------------------------
>
> Key: WFLY-14004
> URL: https://issues.redhat.com/browse/WFLY-14004
> Project: WildFly
> Issue Type: Bug
> Components: Security, Test Suite
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
>
> java.lang.AssertionError: Unexpected status code returned after the authentication. expected:<200> but was:<401>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.jboss.as.test.integration.security.common.Utils$2.run(Utils.java:638)
> at org.jboss.as.test.integration.security.common.Utils$2.run(Utils.java:634)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/javax.security.auth.Subject.doAs(Subject.java:423)
> at org.jboss.as.test.integration.security.common.Utils.makeCallWithKerberosAuthn(Utils.java:634)
> at org.jboss.as.test.integration.security.loginmodules.negotiation.AdvancedLdapLoginModuleTestCase.testDeployment(AdvancedLdapLoginModuleTestCase.java:277)
> at org.jboss.as.test.integration.security.loginmodules.negotiation.AdvancedLdapLoginModuleTestCase.test1(AdvancedLdapLoginModuleTestCase.java:210)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at org.jboss.arquillian.junit.Arquillian$8$1.invokeMethod(Arquillian.java:325)
> at org.jboss.arquillian.junit.MethodInvoker$1.invoke(MethodInvoker.java:18)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:57)
> at jdk.internal.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:50)
> at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:118)
> at jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139)
> at org.jboss.arquillian.junit.MethodInvoker.invoke(MethodInvoker.java:15)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:332)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:215)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:279)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:88)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:66)
> at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:114)
> at jdk.internal.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:273)
> at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka commented on WFLY-14284:
-----------------------------------------
hi [~adrianots],
thanks for you investigation. The changes you did are those which I would recommend to examine.
For the first part of your question. I'm worry there is no clear documentation on remoting protocols and their differences in current WFLY. We have got a documentation issue for that https://issues.redhat.com/browse/JBEAP-10343 (it's created for JBoss EAP product but it's what's missing in WFLY doc as well).
I can only link you to source code like here: https://github.com/wildfly/jboss-ejb-client/blob/4.0.37.Final/src/main/ja...
About your changes. What you can observe is something I didn't realize but sounds logical. The process of the EJB remoting and transaction propagation means creating a record about remote connection when transaction is persisted to transaction object store after the {{prepare}} phase finishes.
Currently it works in the following way. When the remote connection with transaction propagation starts then the WildFly Transaction Client creates a record for recovery knows how to connect to the remote side. It should be under {{data/ejb-txn-recovery}} directory (https://github.com/wildfly/wildfly-transaction-client/blob/1.1.13.Final/s...). Then after prepare the transaction manager makes a record about transaction was prepared under {{data/tx-object-store}}.
Now, your transaction was somehow corrupted as it was saved with HEURISTIC outcome (https://jbossts.blogspot.com/2019/09/heuristic-exceptions.html) to object store. The heuristic state means the recovery manager is not capable to decide what to do with the transaction and the human intervention is needed. That means it won't be finished by WFLY automatically.
The transaction recovery then retries to connect the remote connection saved in {{data/ejb-txn-recovery}} by WFLY txn client. The client saved this connection to be on protocol {{http-remoting}} and thus it retries with that protocol - I assume ti from the error you get that still contains the same class handling the connection client.transaction@1.0.21.Final//org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
When you remove the {{data}} directory then the recover is not retrying to connect to the remote endpoint endlessly, still waiting for somebody to verify the txn in the heuristic state. With deleting the data directory (or it could be just content of the {{data/ejb-txn-recovery}} and {{data/tx-object-store}} you says that the transaction has no further value for you and you start with clean object store. If it's ok from the app state perspective then it's fine.
Now, the only question is - when you get to the same state of having the HEURISTIC transaction while your app server configures the {{remote+http}} protocol - if the result will be only error reported and no issue for the WFLY shutdown process. From what I can remember using the {{remote+http}} should fix that.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5910) Enable range index for JoinNode
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5910?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5910:
-----------------------------------
Sprint: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> Enable range index for JoinNode
> -------------------------------
>
> Key: DROOLS-5910
> URL: https://issues.redhat.com/browse/DROOLS-5910
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.47.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Currently, BetaNode range index works only for NotNode and ExistsNode. Inequality constraints in JoinNode (e.g. $p2 : Person( age > $p1.age )) are not indexed in both standard-drl and exec-model.
> https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...
> * Enable range index for JoinNode
> * Fix issues based on failed tests
> ** Type coercion
> ** executable-model specific errors
> ** maybe more
> * Add more tests for join
> * Add benchmark to confirm the effect
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5883) GDT editor generates wrong DRL if operator 'contains' is used with string literal containing space
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5883?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5883:
-----------------------------------
Sprint: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> GDT editor generates wrong DRL if operator 'contains' is used with string literal containing space
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5883
> URL: https://issues.redhat.com/browse/DROOLS-5883
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.47.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Major
> Labels: guided_decision_table, support
>
> Guided Decision Table editor generate wrong DRL when using 'contains' operator with a string literal containing space., which causes evaluation/build error like.
> [KBase: defaultKieBase]: [ERR 102] Line 7:45 mismatched input ')' in rule "Row 1 rule2"
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-4606) DMN alpha network POC
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-4606?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-4606:
-----------------------------------
Sprint: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2019 Week 41-43 (from Okt 7), 2019 Week 44-46 (from Okt 28), 2019 Week 47-49 (from Nov 18), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> DMN alpha network POC
> ---------------------
>
> Key: DROOLS-4606
> URL: https://issues.redhat.com/browse/DROOLS-4606
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> Start refactoring work to support alpha network
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5877) Support MVEL BLiteral in the exec model
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5877?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5877:
-----------------------------------
Sprint: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> Support MVEL BLiteral in the exec model
> ---------------------------------------
>
> Key: DROOLS-5877
> URL: https://issues.redhat.com/browse/DROOLS-5877
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> It seems like it's already supported in the consequence
>
> [https://github.com/kiegroup/drools/blob/6408b5e1caa1e5c5fe94e45f82e1bedfb...]
>
>
> {code:java}
> package com.myspace.check20201202;
> //from row number: 1
> rule "Row 1 MatteoTable"
> dialect "mvel"
> when
> f1 : Person( age >= 18B )
> then
> f1.setMinor( false );
> end
> //from row number: 2
> rule "Row 2 MatteoTable"
> dialect "mvel"
> when
> f1 : Person( age < 18B )
> then
> f1.setMinor( true );
> end
> package com.myspace.check20201202;
> import java.math.BigDecimal;
> /**
> * This class was automatically generated by the data modeler tool.
> */
> public class Person implements java.io.Serializable {
> static final long serialVersionUID = 1L;
> private java.lang.String name;
> private BigDecimal age;
> private java.lang.Boolean minor;
> public Person() {
> }
> public java.lang.String getName() {
> return this.name;
> }
> public void setName(java.lang.String name) {
> this.name = name;
> }
> public java.lang.Boolean getMinor() {
> return this.minor;
> }
> public void setMinor(java.lang.Boolean minor) {
> this.minor = minor;
> }
> public java.math.BigDecimal getAge() {
> return this.age;
> }
> public void setAge(java.math.BigDecimal age) {
> this.age = age;
> }
> public Person(java.lang.String name, java.math.BigDecimal age,
> java.lang.Boolean minor) {
> this.name = name;
> this.age = age;
> this.minor = minor;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5729) Reorganize drools unit tests
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5729?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5729:
-----------------------------------
Sprint: 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> Reorganize drools unit tests
> ----------------------------
>
> Key: DROOLS-5729
> URL: https://issues.redhat.com/browse/DROOLS-5729
> Project: Drools
> Issue Type: Story
> Components: core engine
> Affects Versions: 7.44.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Motivation: The motivation is to increase test coverage. For example, unit tests which exist under drools-mvel are not tested against executable-model. "Which module is suitable for the unit test?" depends on each test so we may occasionally need to discuss. But basically drools-test-coverage is a good place for DRL based tests because drools-test-coverage may have all dependencies so is flexible to test with any configurations (e.g. alpha compiler network).
> Goals: Increase test coverage. More stable product.
> Impact: During this work, we may find new bugs (because of increased tests). Will need to fix them one-by-one as separated JIRAs.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months