[Red Hat JIRA] (SWSQE-1056) Try OCP 4.6 on IPv6 in PSI
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1056?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1056:
----------------------------------
Sprint: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51 (was: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50)
> Try OCP 4.6 on IPv6 in PSI
> --------------------------
>
> Key: SWSQE-1056
> URL: https://issues.redhat.com/browse/SWSQE-1056
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (SWSQE-1182) DropDown - Optimization of hierarchy.
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1182?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1182:
----------------------------------
Sprint: Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51 (was: Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50)
> DropDown - Optimization of hierarchy.
> -------------------------------------
>
> Key: SWSQE-1182
> URL: https://issues.redhat.com/browse/SWSQE-1182
> Project: Kiali QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Hayk Hovsepyan
> Priority: Major
> Labels: automation
>
> Currently there is a big hierarchy of DropDown objects.
> It needs to be optimized.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14254) WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-14254?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-14254:
--------------------------------------
bq. If I use for both classes {{(a)javax.ejb.Singleton}}
Yes, this won't make a difference because WLFY will still attempt to perform CDI injection (satisfy any {{@Inject}} on the class) into EJB beans.
bq. ... it seems that the CDI-Container does not "recognize" that an instance of the Parent (which is indeed a Singleton) is already created by the EJB-Container.
Yes, this is what I tried (probably poorly :D) to explain above. The instance of {{Parent}} is most likely not considered as complete until it is created and injected into.
And yes, the issue lies somewhere in the integration between EJB and CDI which is done inside WFLY.
> WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
> -----------------------------------------------------------------------
>
> Key: WFLY-14254
> URL: https://issues.redhat.com/browse/WFLY-14254
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 21.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Major
>
> I have following two classes:
>
> The *Parent* class is a "javax.ejb.Singleton" and injects the other Singleton *Child*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.ejb.Singleton
> @javax.ejb.Startup
> public class Parent {
>
> @Inject
> private Child child;
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Parent (" + getId() + ") created.");
> child.sendMessage();
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> The *Child* class is a "javax.inject.Singleton" and injects the other Singleton *Parent*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.inject.Singleton
> //(a)javax.ejb.Singleton
> public class Child {
>
> private Parent parent;
>
> // no-args constructor not needed for @javax.inject.Singleton
> public Child() {
> }
>
> // the parent should be injected if already created by container
> @Inject
> public Child(Parent parent) {
> this.parent = parent;
> }
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Child (" + getId() + ") created.");
> }
>
> public void sendMessage() {
> System.out.println("> Child called to parent: " + parent.getId());
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> As both are Singletons, the "postConstruct()" for those two classes should only be called once. The Child uses a constructor with an injected Parent thus it should look for it if this instance is already created. However, it seems that the container tries to create the Parent-Instance twice, hence the following error:
> {code:java}
> Caused by: java.lang.IllegalStateException: WFLYEJB0132: @PostConstruct method of EJB singleton Parent of type io.Parent has been recursively invoked
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:199)
> ... 101 more{code}
> Of course, I can use "@Inject Parent parent" within the Singleton "Child" instead of constructor injection, then no error is shown. However, constructor injection should also work, or? Is this a bug or is this intended?
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14254) WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
by nimo stephan (Jira)
[ https://issues.redhat.com/browse/WFLY-14254?page=com.atlassian.jira.plugi... ]
nimo stephan edited comment on WFLY-14254 at 1/4/21 8:54 AM:
-------------------------------------------------------------
{code:java}
>Basically, this is grey area between specs because they don't exactly specify how EJB and CDI container interoperate..{code}
If I use for both classes
{code:java}
@javax.ejb.Singleton
{code}
then the same error occurs. I guess, it is because of the CDI-"@Inject" from the constructor injection within the Singleton "Child".
I think, in JEE Containers, the ordering is the following:
# At first, EJB's are initialized.
# Afterwards, the CDI-Runtime starts (e.g., "@Inject")
However, looking at the error above, it seems that the CDI-Container does not "recognize" that an instance of the Parent (which is indeed a Singleton) is already created by the EJB-Container. Which container has the responsibility for this "recognition" - the EJB-Container or the CDI-Container? I think Wildfly, because CDI is not aware of EJB and vice versa.
was (Author: nimo22):
{code:java}
>Basically, this is grey area between specs because they don't exactly specify how EJB and CDI container interoperate..{code}
If I use for both classes
@javax.ejb.Singleton
then the same error occurs. I guess, it is because of the CDI-"@Inject" from the constructor injection within the Singleton "Child".
I think, in JEE Containers, the ordering is the following:
# At first, EJB's are initialized.
# Afterwards, the CDI-Runtime starts (e.g., "@Inject")
However, looking at the error above, it seems that the CDI-Container does not "recognize" that an instance of the Parent (which is indeed a Singleton) is already created by the EJB-Container. Which container has the responsibility for this "recognition" - the EJB-Container or the CDI-Container? I think Wildfly, because CDI is not aware of EJB and vice versa.
> WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
> -----------------------------------------------------------------------
>
> Key: WFLY-14254
> URL: https://issues.redhat.com/browse/WFLY-14254
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 21.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Major
>
> I have following two classes:
>
> The *Parent* class is a "javax.ejb.Singleton" and injects the other Singleton *Child*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.ejb.Singleton
> @javax.ejb.Startup
> public class Parent {
>
> @Inject
> private Child child;
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Parent (" + getId() + ") created.");
> child.sendMessage();
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> The *Child* class is a "javax.inject.Singleton" and injects the other Singleton *Parent*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.inject.Singleton
> //(a)javax.ejb.Singleton
> public class Child {
>
> private Parent parent;
>
> // no-args constructor not needed for @javax.inject.Singleton
> public Child() {
> }
>
> // the parent should be injected if already created by container
> @Inject
> public Child(Parent parent) {
> this.parent = parent;
> }
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Child (" + getId() + ") created.");
> }
>
> public void sendMessage() {
> System.out.println("> Child called to parent: " + parent.getId());
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> As both are Singletons, the "postConstruct()" for those two classes should only be called once. The Child uses a constructor with an injected Parent thus it should look for it if this instance is already created. However, it seems that the container tries to create the Parent-Instance twice, hence the following error:
> {code:java}
> Caused by: java.lang.IllegalStateException: WFLYEJB0132: @PostConstruct method of EJB singleton Parent of type io.Parent has been recursively invoked
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:199)
> ... 101 more{code}
> Of course, I can use "@Inject Parent parent" within the Singleton "Child" instead of constructor injection, then no error is shown. However, constructor injection should also work, or? Is this a bug or is this intended?
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14254) WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
by nimo stephan (Jira)
[ https://issues.redhat.com/browse/WFLY-14254?page=com.atlassian.jira.plugi... ]
nimo stephan edited comment on WFLY-14254 at 1/4/21 8:54 AM:
-------------------------------------------------------------
{code:java}
>Basically, this is grey area between specs because they don't exactly specify how EJB and CDI container interoperate..{code}
If I use for both classes
@javax.ejb.Singleton
then the same error occurs. I guess, it is because of the CDI-"@Inject" from the constructor injection within the Singleton "Child".
I think, in JEE Containers, the ordering is the following:
# At first, EJB's are initialized.
# Afterwards, the CDI-Runtime starts (e.g., "@Inject")
However, looking at the error above, it seems that the CDI-Container does not "recognize" that an instance of the Parent (which is indeed a Singleton) is already created by the EJB-Container. Which container has the responsibility for this "recognition" - the EJB-Container or the CDI-Container? I think Wildfly, because CDI is not aware of EJB and vice versa.
was (Author: nimo22):
{code:java}
>Basically, this is grey area between specs because they don't exactly specify how EJB and CDI container interoperate..{code}
If I use for both classes
@javax.ejb.Singleton
then the same error occurs. I guess, it is because of the CDI-"@Inject" from the constructor injection within the Singleton "Child".
I think, in JEE Containers, the ordering is the following:
# At first, EJB's are initialized.
# Afterwards, the CDI-Runtime starts (e.g., "@Inject")
However, looking at the error above, it seems that the CDI-Container does not "recognize" that an instance of the Parent (which is indeed a Singleton) is already created by the EJB-Container. Which container has the responsibility for this "recognition" - the EJB-Container or the CDI-Container? I think Wildfly, because CDI is not aware of EJB and vice versa.
> WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
> -----------------------------------------------------------------------
>
> Key: WFLY-14254
> URL: https://issues.redhat.com/browse/WFLY-14254
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 21.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Major
>
> I have following two classes:
>
> The *Parent* class is a "javax.ejb.Singleton" and injects the other Singleton *Child*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.ejb.Singleton
> @javax.ejb.Startup
> public class Parent {
>
> @Inject
> private Child child;
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Parent (" + getId() + ") created.");
> child.sendMessage();
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> The *Child* class is a "javax.inject.Singleton" and injects the other Singleton *Parent*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.inject.Singleton
> //(a)javax.ejb.Singleton
> public class Child {
>
> private Parent parent;
>
> // no-args constructor not needed for @javax.inject.Singleton
> public Child() {
> }
>
> // the parent should be injected if already created by container
> @Inject
> public Child(Parent parent) {
> this.parent = parent;
> }
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Child (" + getId() + ") created.");
> }
>
> public void sendMessage() {
> System.out.println("> Child called to parent: " + parent.getId());
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> As both are Singletons, the "postConstruct()" for those two classes should only be called once. The Child uses a constructor with an injected Parent thus it should look for it if this instance is already created. However, it seems that the container tries to create the Parent-Instance twice, hence the following error:
> {code:java}
> Caused by: java.lang.IllegalStateException: WFLYEJB0132: @PostConstruct method of EJB singleton Parent of type io.Parent has been recursively invoked
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:199)
> ... 101 more{code}
> Of course, I can use "@Inject Parent parent" within the Singleton "Child" instead of constructor injection, then no error is shown. However, constructor injection should also work, or? Is this a bug or is this intended?
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (WFLY-14254) WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
by nimo stephan (Jira)
[ https://issues.redhat.com/browse/WFLY-14254?page=com.atlassian.jira.plugi... ]
nimo stephan commented on WFLY-14254:
-------------------------------------
{code:java}
>Basically, this is grey area between specs because they don't exactly specify how EJB and CDI container interoperate..{code}
If I use for both classes
@javax.ejb.Singleton
then the same error occurs. I guess, it is because of the CDI-"@Inject" from the constructor injection within the Singleton "Child".
I think, in JEE Containers, the ordering is the following:
# At first, EJB's are initialized.
# Afterwards, the CDI-Runtime starts (e.g., "@Inject")
However, looking at the error above, it seems that the CDI-Container does not "recognize" that an instance of the Parent (which is indeed a Singleton) is already created by the EJB-Container. Which container has the responsibility for this "recognition" - the EJB-Container or the CDI-Container? I think Wildfly, because CDI is not aware of EJB and vice versa.
> WFLYEJB0132: @PostConstruct method of EJB singleton recursively invoked
> -----------------------------------------------------------------------
>
> Key: WFLY-14254
> URL: https://issues.redhat.com/browse/WFLY-14254
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 21.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Major
>
> I have following two classes:
>
> The *Parent* class is a "javax.ejb.Singleton" and injects the other Singleton *Child*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.ejb.Singleton
> @javax.ejb.Startup
> public class Parent {
>
> @Inject
> private Child child;
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Parent (" + getId() + ") created.");
> child.sendMessage();
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> The *Child* class is a "javax.inject.Singleton" and injects the other Singleton *Parent*:
> {code:java}
> import javax.annotation.PostConstruct;
> import javax.inject.Inject;
> @javax.inject.Singleton
> //(a)javax.ejb.Singleton
> public class Child {
>
> private Parent parent;
>
> // no-args constructor not needed for @javax.inject.Singleton
> public Child() {
> }
>
> // the parent should be injected if already created by container
> @Inject
> public Child(Parent parent) {
> this.parent = parent;
> }
>
> @PostConstruct
> private void postConstruct() {
> System.out.println("> Child (" + getId() + ") created.");
> }
>
> public void sendMessage() {
> System.out.println("> Child called to parent: " + parent.getId());
> }
>
> public Integer getId() {
> return this.hashCode();
> }
> }
> {code}
>
> As both are Singletons, the "postConstruct()" for those two classes should only be called once. The Child uses a constructor with an injected Parent thus it should look for it if this instance is already created. However, it seems that the container tries to create the Parent-Instance twice, hence the following error:
> {code:java}
> Caused by: java.lang.IllegalStateException: WFLYEJB0132: @PostConstruct method of EJB singleton Parent of type io.Parent has been recursively invoked
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:199)
> ... 101 more{code}
> Of course, I can use "@Inject Parent parent" within the Singleton "Child" instead of constructor injection, then no error is shown. However, constructor injection should also work, or? Is this a bug or is this intended?
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (DROOLS-5897) Compound BigDecimal operator is translated to assignOperator in MVEL
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5897?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5897:
---------------------------------
Sprint: 2020 Week 52-03 (from Dec 21)
> Compound BigDecimal operator is translated to assignOperator in MVEL
> --------------------------------------------------------------------
>
> Key: DROOLS-5897
> URL: https://issues.redhat.com/browse/DROOLS-5897
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> {code:java}
> @Test
> @Ignore("without B it doesn't work on MVEL")
> public void testCompoundOperator() throws Exception {
> // DROOLS-5894
> String drl =
> "import " + Person.class.getCanonicalName() + "\n" +
> "dialect \"mvel\"\n" +
> "rule R\n" +
> "when\n" +
> " $p : Person( age >= 26 )\n" +
> "then\n" +
> " $p.money += 50000;\n" +
> "end";
> KieSession ksession = getKieSession(drl);
> Person john = new Person("John", 30);
> john.setMoney( new BigDecimal( 70000 ) );
> ksession.insert(john);
> assertEquals(1, ksession.fireAllRules());
> assertEquals(new BigDecimal( 120000 ), john.getMoney());
> }{code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 4 months
[Red Hat JIRA] (DROOLS-5877) Support MVEL BLiteral in the exec model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5877?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5877:
---------------------------------
Story Points: 3
> 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)
3 years, 4 months