[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)
5 years, 11 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)
5 years, 11 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)
5 years, 11 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:
---------------------------------
Steps to Reproduce:
logs are below showing the DNS_PING query where the two entries are found - port 8888 is the web port, port 8889 is the jgroups port. Undertow logs a failure for the probe at DEBUG level, but jgroups is logging the failed probe at ERROR level.
{code:java}
2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: sending discovery requests to [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,357 DEBUG [io.undertow.request.io] (default I/O-2) UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character in request-target at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:389) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479) 2020-07-22 17:51:03,358 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver [172.17.0.10:57508 - 172.29.11.55:8888]-22,ejb,463dfca1ff73) JGRP000030: 463dfca1ff73: failed handling incoming message: java.io.EOFException at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202) at org.jgroups@4.1.9.Final//org.jgroups.util.Util.readMessageBatch(Util.java:1226) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.handleMessageBatch(TP.java:1448) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.receive(TP.java:1440) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:300) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextReferenceExecutor.execute(ContextReferenceExecutor.java:49) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextualExecutor$1.run(ContextualExecutor.java:70) at java.base/java.lang.Thread.run(Thread.java:834)
{code}
was:
logs are below showing the DNS_PING query where the two entries are found - port 8888 is the web port, port 8889 is the jgroups port. Undertow logs a failure for the probe at DEBUG level, but jgroups is logging the failed probe at ERROR level.
{noformat}
2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: entries collected from DNS (in 3 ms): [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,356 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-5,null,463dfca1ff73) 463dfca1ff73: sending discovery requests to [172.29.11.55:8889, 172.29.11.55:8888]2020-07-22 17:51:03,357 DEBUG [io.undertow.request.io] (default I/O-2) UT005014: Failed to parse request: io.undertow.util.BadRequestException: UT000165: Invalid character in request-target at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:389) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100) at io.undertow.core@2.1.0.Final//io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) at org.jboss.xnio@3.7.7.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) at org.jboss.xnio.nio@3.7.7.Final//org.xnio.nio.WorkerThread.run(WorkerThread.java:479) 2020-07-22 17:51:03,358 ERROR [org.jgroups.protocols.TCP] (Connection.Receiver [172.17.0.10:57508 - 172.29.11.55:8888]-22,ejb,463dfca1ff73) JGRP000030: 463dfca1ff73: failed handling incoming message: java.io.EOFException at java.base/java.io.DataInputStream.readFully(DataInputStream.java:202) at org.jgroups@4.1.9.Final//org.jgroups.util.Util.readMessageBatch(Util.java:1226) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.handleMessageBatch(TP.java:1448) at org.jgroups@4.1.9.Final//org.jgroups.protocols.TP.receive(TP.java:1440) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.BaseServer.receive(BaseServer.java:171) at org.jgroups@4.1.9.Final//org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:300) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextReferenceExecutor.execute(ContextReferenceExecutor.java:49) at org.jboss.as.clustering.common@19.1.0.Final//org.jboss.as.clustering.context.ContextualExecutor$1.run(ContextualExecutor.java:70) at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
> 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
>
> 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-2494) DNS_PING and failed probes
by Dewayne McNair (Jira)
Dewayne McNair created JGRP-2494:
------------------------------------
Summary: 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
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] (DROOLS-5061) DMN strongly typed codegen DMNContext and DMNResult
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5061?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5061:
-----------------------------------
Description:
*Motivation*: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
*Goals*: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
*Impacts*: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
was:
Motivation: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
Goals: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Impacts: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
> DMN strongly typed codegen DMNContext and DMNResult
> ---------------------------------------------------
>
> Key: DROOLS-5061
> URL: https://issues.redhat.com/browse/DROOLS-5061
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> *Motivation*: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
> *Goals*: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> *Impacts*: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
> A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Surface and interface common to:
> * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
> * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
> ** for Quarkus based, use RegisterForReflection annotation
> ** use MP validation for allowedvalues
> * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
> Documentation:
> * the programmatic use of the generated classes, directly, is DISCOURAGED
> * if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-4605) DMN alpha network
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-4605?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-4605:
-----------------------------------
Description:
*Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
*Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
*Impact*: alpha network compiler code refactors for the better use of.
One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
> DMN alpha network
> -----------------
>
> Key: DROOLS-4605
> URL: https://issues.redhat.com/browse/DROOLS-4605
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> *Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
> *Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
> *Impact*: alpha network compiler code refactors for the better use of.
> One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5061) DMN strongly typed codegen DMNContext and DMNResult
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5061?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5061:
-----------------------------------
Description:
Motivation: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
Goals: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Impacts: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
was:
A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
Surface and interface common to:
* BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
* Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
** for Quarkus based, use RegisterForReflection annotation
** use MP validation for allowedvalues
* DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
Documentation:
* the programmatic use of the generated classes, directly, is DISCOURAGED
* if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
> DMN strongly typed codegen DMNContext and DMNResult
> ---------------------------------------------------
>
> Key: DROOLS-5061
> URL: https://issues.redhat.com/browse/DROOLS-5061
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> Motivation: currently interacting with DMN evaluation is mostly based on dynamic (map-based) data structure to exchange IN/OUT. This is not always fully satisfactory, for instance when interacting over REST or from/back-to BPMN.
> Goals: A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Impacts: integration with BPMN, integration with Kogito for OpenAPI/Swagger, new APIs for DMN, will need documentation.
> A codegen facility is required to generate statically code strongly typed for the input/output of a DMN model, considering also the data types defined inside the DMN model as ItemDefinition.
> Surface and interface common to:
> * BPMN integration: when invoking DMN from BPMN, the return of the evaluation is a Map and not the domain model
> * Kogito/OpenAPI/Swagger: when using the codegenerated version, annotation shall explain the swagger API the expected input/output type of the REST request for DMN
> ** for Quarkus based, use RegisterForReflection annotation
> ** use MP validation for allowedvalues
> * DMN Editor: when importing a Java Class in the editor, it shall use the user-supplied Java Class
> Documentation:
> * the programmatic use of the generated classes, directly, is DISCOURAGED
> * if anything, a programmatic use will eventually be stable by making use of the available interfaces in kie-dmn-core
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13690) InfinispanRoutingProvider generates wrong service names when server name contain a dot.
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13690:
-----------------------------------
Summary: InfinispanRoutingProvider generates wrong service names when server name contain a dot.
Key: WFLY-13690
URL: https://issues.redhat.com/browse/WFLY-13690
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 20.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The problematic pattern:
{code:java}
BinaryRequirement requirement = ...;
ServiceName.parse(requirement.resolve(container, cache));
{code}
should be:
{code:java}
ServiceName.parse(requirement.getName()).append(container, cache);
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months