[JBoss JIRA] (DROOLS-5525) Fix PMML for Kogito' native compilation i
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5525:
----------------------------------------
Summary: Fix PMML for Kogito' native compilation i
Key: DROOLS-5525
URL: https://issues.redhat.com/browse/DROOLS-5525
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Currently PMML (inside drools repo) uses some reflaction/dynamic class discovery that is uncompatible with Kogito native compilation.
This task imply:
1) modify PMML (inside drools repo) to avoid reflection/dynamic class discovery
2) verify PMML native compilation functionality inside kogito-runtimes
3) create tests/ verify PMML native compilation functionality inside kogito-examples (both as standalone and in DMN-PMML integration)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2494:
--------------------------------
Can this issue be closed with resolution=upgrade?
> 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)
5 years, 11 months
[JBoss JIRA] (JGRP-2493) RELAY does not use protocol stack supplied programmatically
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2493?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2493:
---------------------------
Fix Version/s: 5.0.0.Final
> RELAY does not use protocol stack supplied programmatically
> -----------------------------------------------------------
>
> Key: JGRP-2493
> URL: https://issues.redhat.com/browse/JGRP-2493
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.4
> Reporter: S Pokutniy
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> RELAY does not use protocol stack supplied programmatically (i.e. stack which was set by using relay.setProtocolStack(protocolStack). Even though the stack is used in init(), the function below only relies on bridge_props file. Even though using an XML file is mostly possible, it becomes problematic when a custom SSLContext needs to be used in SSL_KEY_EXCHANGE, which can now only be set programmatically.
>
> protected void createBridge() {
> try {
> if(log.isTraceEnabled())
> log.trace("I'm the coordinator, creating a channel (props=" + bridge_props + ", cluster_name=" + bridge_name + ")");
> {color:#FF0000}bridge=new JChannel(bridge_props);{color}
> bridge.setDiscardOwnMessages(true); // don't receive my own messages
> bridge.setReceiver(new Receiver());
> bridge.connect(bridge_name);
> }
> catch(Exception e) {
> log.error(Util.getMessage("FailedCreatingBridgeChannelProps") + bridge_props + ")", e);
> }
> }
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[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)
5 years, 11 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)
5 years, 11 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)
5 years, 11 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)
5 years, 11 months