[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ]
Jozef Marko commented on DROOLS-5009:
-------------------------------------
[~manstis] [~dadossan] actually I think a little bit more about this. I haven't written the expected behavior. Do we all agree that informing user about an error after clicking the button is too late? If no, then we can close jira. If yes, we should agree on one options bellow:
- Import is not possible if such field is present, user is informed
- Import omits particular fields that are not DMN valid, user is informed
- Import adapts particular fields to be DMN valid, user is informed
*User is informed* in all cases above is question for UX I guess.
> DMN Designer convert java class with invalid DMN identiefier
> ------------------------------------------------------------
>
> Key: DROOLS-5009
> URL: https://issues.redhat.com/browse/DROOLS-5009
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-05 16-21-10.png
>
>
> There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN.
> for example assume this java class and try to convert it into DMN data type, you will get an error as attached.
> {code:java}
> public class Address {
> private int number;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5011) Multiselect dropdown for enumerated values
by Toni Rikkola (Jira)
Toni Rikkola created DROOLS-5011:
------------------------------------
Summary: Multiselect dropdown for enumerated values
Key: DROOLS-5011
URL: https://issues.redhat.com/browse/DROOLS-5011
Project: Drools
Issue Type: Bug
Components: Guided Template Editor
Reporter: Toni Rikkola
Assignee: Toni Rikkola
In earlier versions business central editor for a Guided Rule Template would display list (multiselect drop down )of enumerated values in Data tab if the user added a Template Key of type Enumerations, but in latest version it's shown as a normal text field not displaying enum values drop down .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-11939) FineDatabasePersistenceWebFailoverTestCase fails intermittently
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-11939?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-11939:
---------------------------------------
[~tomjenkinson] That is a different failure, namely that run failed with
Caused by: java.lang.InterruptedException: Cache web/FineDatabasePersistenceWebFailoverTestCase.war failed to establish view [node-1, node-2, node-3] within 15000 ms. Current view is: [node-1]
which is a problem with timely discovery we are looking into already.
> FineDatabasePersistenceWebFailoverTestCase fails intermittently
> ---------------------------------------------------------------
>
> Key: WFLY-11939
> URL: https://issues.redhat.com/browse/WFLY-11939
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: No Release
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 17.0.0.Final
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-12881) Cannot customize split behavior and merge policy for Infinispan partition handling
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-12881:
----------------------------------
Affects Version/s: 19.0.0.Beta1
> Cannot customize split behavior and merge policy for Infinispan partition handling
> ----------------------------------------------------------------------------------
>
> Key: WFLY-12881
> URL: https://issues.redhat.com/browse/WFLY-12881
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.1.Final, 19.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 20.0.0.Beta1
>
>
> Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of any data conflicts occurs.
> Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13064) EJB client-side interceptor failure when using HTTPRemoting Protocol
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13064?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13064:
-----------------------------------
looks like the failed test {{testHttpRemotingProtocol}} has an execution dependency on the other test. So running this test alone will always fail, and this was expected (this test is not to be run alone).
It will pass when running the whole test case:
cd testsuite/integration/multinode
mvn clean install -Dtest=RemoteProtocolChangeClientInterceptorTestCase
> EJB client-side interceptor failure when using HTTPRemoting Protocol
> --------------------------------------------------------------------
>
> Key: WFLY-13064
> URL: https://issues.redhat.com/browse/WFLY-13064
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Affects Versions: 19.0.0.Beta1
> Reporter: Francesco Marchioni
> Assignee: Cheng Fang
> Priority: Major
> Attachments: surefire-reports-RemoteProtocolChangeClientInterceptorTestCase.zip
>
>
> The following [test|https://github.com/wildfly/wildfly/blob/master/testsuite/integration...] fails in counting the EJB Client Interceptor count, when the HTTP Remoting Protocol is used:
> {code:java}
> @Test
> @InSequence(2)
> @OperateOnDeployment("client")
> public void testHttpRemotingProtocol() throws Exception {
> final Hashtable<String, String> props = new Hashtable<>();
> props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> props.put(Context.PROVIDER_URL, "http-remoting://" + TestSuiteEnvironment.getServerAddress() + ":"
> + (TestSuiteEnvironment.getHttpPort() + Integer.parseInt(getSystemProperty("jboss.socket.binding.port-offset", "100"))));
> StatelessRemote bean = getRemote(new InitialContext(props));
> Assert.assertNotNull(bean);
> // StatelessBean.methodCount field should equal 2 after second invoking (methodCount is a static field and is shared within a single JVM)
> Assert.assertEquals(ProtocolSampleClientInterceptor.COUNT + 2, bean.method());
> }
> {code}
> Stack Trace:
> {code:java}
> 14:46:01 [ERROR] testHttpRemotingProtocol(org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase) Time elapsed: 0.77 s <<< FAILURE!
> 14:46:01 java.lang.AssertionError: expected:<12> but was:<11>
> 14:46:01 at org.junit.Assert.fail(Assert.java:88)
> 14:46:01 at org.junit.Assert.failNotEquals(Assert.java:834)
> 14:46:01 at org.junit.Assert.assertEquals(Assert.java:645)
> 14:46:01 at org.junit.Assert.assertEquals(Assert.java:631)
> 14:46:01 at org.jboss.as.test.multinode.clientinterceptor.protocol.RemoteProtocolChangeClientInterceptorTestCase.testHttpRemotingProtocol(RemoteProtocolChangeClientInterceptorTestCase.java:130)
> {code}
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13065) Options for reverse-proxy max-request-time and connection-idle-timeout are specified as seconds
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFLY-13065?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero updated WFLY-13065:
-------------------------------------------
Component/s: Web (Undertow)
Description:
In the reverse-proxy configuration the options {{max-request-time}} and {{connection-idle-timeout}} are specified and managed as seconds in CLI, when they are really milliseconds in undertow.
{noformat}
/subsystem=undertow/configuration=handler/reverse-proxy=LBProxy:read-resource-description
...
"connection-idle-timeout" => {
"type" => INT,
"description" => "The amount of time a connection can be idle before it will be closed. Connections will not time out
once the pool size is down to the configured minimum (as configured by cached-connections-per-thread)",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"default" => 60L,
"unit" => "SECONDS",
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...
"max-request-time" => {
"type" => INT,
"description" => "The maximum time that a proxy request can be active for, before being killed",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"default" => -1,
"unit" => "SECONDS",
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
...
{noformat}
The class [ReverseProxyHandler|https://github.com/wildfly/wildfly/blob/master/undert...] just passes the value (no modification) to undertow and it's clearly millis in undertow, for example the [max-request-time|https://github.com/undertow-io/undertow/blob/master/core...].
I has suffered this confusion myself doing some tests, I set 60 as the max request time, and it was too short in my env (because they are millis instead of seconds).
We need to change description to millis to respect current configurations.
Priority: Minor (was: Major)
Affects Version/s: 19.0.0.Beta1
> Options for reverse-proxy max-request-time and connection-idle-timeout are specified as seconds
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-13065
> URL: https://issues.redhat.com/browse/WFLY-13065
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Minor
>
> In the reverse-proxy configuration the options {{max-request-time}} and {{connection-idle-timeout}} are specified and managed as seconds in CLI, when they are really milliseconds in undertow.
> {noformat}
> /subsystem=undertow/configuration=handler/reverse-proxy=LBProxy:read-resource-description
> ...
> "connection-idle-timeout" => {
> "type" => INT,
> "description" => "The amount of time a connection can be idle before it will be closed. Connections will not time out
> once the pool size is down to the configured minimum (as configured by cached-connections-per-thread)",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => 60L,
> "unit" => "SECONDS",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...
> "max-request-time" => {
> "type" => INT,
> "description" => "The maximum time that a proxy request can be active for, before being killed",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => -1,
> "unit" => "SECONDS",
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> ...
> {noformat}
> The class [ReverseProxyHandler|https://github.com/wildfly/wildfly/blob/master/undert...] just passes the value (no modification) to undertow and it's clearly millis in undertow, for example the [max-request-time|https://github.com/undertow-io/undertow/blob/master/core...].
> I has suffered this confusion myself doing some tests, I set 60 as the max request time, and it was too short in my env (because they are millis instead of seconds).
> We need to change description to millis to respect current configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ]
Michael Anstis commented on DROOLS-5009:
----------------------------------------
[~dadossan] We have a {{DMNClientServicesProxy.isValidVariableName(..)}} method we could use.
It might be best to add a similar method to the interface to support "batch" validation to avoid a excessive network chat (for each field name). You could invoke that with all proposed field names and the method could return which are valid. Invalid ones would need to be cleansed (IDK if adding an underscore is enough to make it valid but worth consideration).
> DMN Designer convert java class with invalid DMN identiefier
> ------------------------------------------------------------
>
> Key: DROOLS-5009
> URL: https://issues.redhat.com/browse/DROOLS-5009
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-05 16-21-10.png
>
>
> There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN.
> for example assume this java class and try to convert it into DMN data type, you will get an error as attached.
> {code:java}
> public class Address {
> private int number;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months