[JBoss JIRA] (DROOLS-4942) DMN DT Analysis hit policy recommender
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4942?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-4942 at 7/23/20 2:27 AM:
-----------------------------------------------------------------
Message level is followed-up with [DROOLS-5363]
was (Author: tari_manga):
followed-up by https://issues.redhat.com/browse/DROOLS-5363
> DMN DT Analysis hit policy recommender
> --------------------------------------
>
> Key: DROOLS-4942
> URL: https://issues.redhat.com/browse/DROOLS-4942
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: screenshot-1.png
>
>
> Implement an heuristic for hit policy recommendation when dealing with single hit policies.
> If there are Gaps, no recommendations.
> If No Gaps and no Overlaps: recommend UNIQUE where possible.
> If No Gaps , but Overlaps with same output: recommend ANY
> If No Gaps , but Overlaps with different output: recommend PRIORITY where possible
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13433 at 7/22/20 8:48 PM:
---------------------------------------------------------------------
I'm running into a problem with the LegacyConfigXTestSuite tests in the mixed-domain testsuite module, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities.
These tests do the following:
* start a master HC and slave HC using a given domain.xml file
* for each profile p in \{default, ha, full, full-ha} from the domain.xml file:
** start a server using profile p and wait for it to start
** check it has the correct profile name
** check we can connect via HTTP
** clean up the server
An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640.
The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests.
This is a mystery to me. [~yersan], [~brian.stansberry] any ideas?
was (Author: rachmato):
I'm running into a problem with the LegacyConfigXTestSuite tests, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities.
These tests do the following:
* start a master HC and slave HC using a given domain.xml file
* for each profile p in \{default, ha, full, full-ha} from the domain.xml file:
** start a server using profile p and wait for it to start
** check it has the correct profile name
** check we can connect via HTTP
** clean up the server
An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640.
The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests.
This is a mystery to me. [~yersan], [~brian.stansberry] any ideas?
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt
>
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13433:
--------------------------------------------
I'm running into a problem with the LegacyConfigXTestSuite tests, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities.
These tests do the following:
* start a master HC and slave HC using a given domain.xml file
* for each profile p in \{default, ha, full, full-ha} from the domain.xml file:
** start a server using profile p and wait for it to start
** check it has the correct profile name
** check we can connect via HTTP
** clean up the server
An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640.
The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests.
This is a mystery to me. [~yersan], [~brian.stansberry] any ideas?
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt
>
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13691) Ajax call causes exception: Target Unreachable, 'null' returned null
by erick leal (Jira)
[ https://issues.redhat.com/browse/WFLY-13691?page=com.atlassian.jira.plugi... ]
erick leal updated WFLY-13691:
------------------------------
Description:
I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v...
Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate]
When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
XHTML:
{code:java}
<f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code}
beans
{code:java}
import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code}
model
{code:java}
public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code}
You also need to set in web.xml the following param
{code:java}
<context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code}
was:
I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v...
Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate]
When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
XHTML:
{{}}
{code:java}
<f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code}
{{}}
{{}}
{code:java}
import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code}
{{}}
{{}}
{code:java}
public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code}
{{}}
You also need to set in web.xml the following param {{}}
{code:java}
<context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code}
{{}}
> Ajax call causes exception: Target Unreachable, 'null' returned null
> --------------------------------------------------------------------
>
> Key: WFLY-13691
> URL: https://issues.redhat.com/browse/WFLY-13691
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 20.0.1.Final
> Reporter: erick leal
> Assignee: Farah Juma
> Priority: Major
>
> I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v...
> Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate]
> When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
> XHTML:
>
> {code:java}
> <f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code}
> beans
> {code:java}
> import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code}
> model
> {code:java}
> public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code}
> You also need to set in web.xml the following param
> {code:java}
> <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13691) Ajax call causes exception: Target Unreachable, 'null' returned null
by erick leal (Jira)
erick leal created WFLY-13691:
---------------------------------
Summary: Ajax call causes exception: Target Unreachable, 'null' returned null
Key: WFLY-13691
URL: https://issues.redhat.com/browse/WFLY-13691
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 20.0.1.Final
Reporter: erick leal
Assignee: Farah Juma
I still have a problem with JSF 2.3 related to ViewParam, I tested it with WildFly 20.0.1 and the bug is still there. I tried to reduce the code, but I was only able to simulate the error using PrimeFaces. The code is in the repository [https://github.com/erickdeoliveiraleal/primefaces-test/tree/v...
Note that Wildfly already incorporated all the fixes recently done by [@soul2zimate|https://github.com/soul2zimate]
When you click on button the second time a exception happens, this is not the case when using mojarra 2.2, myfaces 2.2 or myfaces 2.3
XHTML:
{{}}
{code:java}
<f:metadata> <f:viewParam id="id" name="id" value="#{testView.testClass.id}" /> </f:metadata> <h:form> <p:commandButton update="@form" /> <p:dataTable var="m" selectionMode="single" selection="#{testView.testClass}" rowKey="#{m.id}" value="#{testView.testClasses}"> </p:dataTable> </h:form>{code}
{{}}
{{}}
{code:java}
import java.io.Serializable; import java.util.List; import javax.annotation.PostConstruct; import javax.faces.view.ViewScoped; import javax.inject.Named; @Named @ViewScoped public class TestView implements Serializable { private TestClass testClass; private List<TestClass> testClasses; @PostConstruct public void init() { testClass = new TestClass(); } public TestClass getTestClass() { return testClass; } public void setTestClass(TestClass testClass) { this.testClass = testClass; } public List<TestClass> getTestClasses() { return testClasses; } public void setTestClasses(List<TestClass> testClasses) { this.testClasses = testClasses; } }{code}
{{}}
{{}}
{code:java}
public class TestClass { Integer id; public Integer getId() { return id; } public void setId(Integer id) { this.id = id; } }{code}
{{}}
You also need to set in web.xml the following param {{}}
{code:java}
<context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param>{code}
{{}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Dewayne McNair commented on JGRP-2494:
--------------------------------------
I forced an upgrade to 4.2.4.Final and that seems to have resolved the issue.
> DNS_PING and failed probes
> --------------------------
>
> Key: JGRP-2494
> URL: https://issues.redhat.com/browse/JGRP-2494
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dewayne McNair
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGRP-2494.txt
>
>
> Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Dewayne McNair updated JGRP-2494:
---------------------------------
Attachment: JGRP-2494.txt
> DNS_PING and failed probes
> --------------------------
>
> Key: JGRP-2494
> URL: https://issues.redhat.com/browse/JGRP-2494
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dewayne McNair
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGRP-2494.txt
>
>
> Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months