February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4024) Move keyboard shortcuts to menus in DMN.

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4024?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4024: ------------------------------------- [~karreiro] I guess this is done now? > Move keyboard shortcuts to menus in DMN. > ---------------------------------------- > > Key: DROOLS-4024 > URL: https://issues.redhat.com/browse/DROOLS-4024 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Guilherme Gomes > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: currentMenu.png, insert+.png, kebab-shortcuts.png > > > As a business analyst practitioner, I would like to view the keyboard shortcuts in the context of the menu actions that they refer to. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-13066) Upgrade Apache CXF from 3.3.4 to 3.3.5

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-13066?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-13066: ----------------------------- Component/s: Web Services > Upgrade Apache CXF from 3.3.4 to 3.3.5 > -------------------------------------- > > Key: WFLY-13066 > URL: https://issues.redhat.com/browse/WFLY-13066 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 19.0.0.Beta1 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > Labels: downstream_dependency > > Tag: https://github.com/apache/cxf/releases/tag/cxf-3.3.5 > Diff: https://github.com/apache/cxf/compare/cxf-3.3.4...cxf-3.3.5 > Commit hash: https://github.com/apache/cxf/commit/c2c912024f22d498e343bbd52e57a65f3fd4... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13066) Upgrade Apache CXF from 3.3.4 to 3.3.5

by Chao Wang (Jira)

Chao Wang created WFLY-13066: -------------------------------- Summary: Upgrade Apache CXF from 3.3.4 to 3.3.5 Key: WFLY-13066 URL: https://issues.redhat.com/browse/WFLY-13066 Project: WildFly Issue Type: Component Upgrade Components: Build System Affects Versions: 19.0.0.Beta1 Reporter: Chao Wang Assignee: Chao Wang Tag: https://github.com/apache/cxf/releases/tag/cxf-3.3.5 Diff: https://github.com/apache/cxf/compare/cxf-3.3.4...cxf-3.3.5 Commit hash: https://github.com/apache/cxf/commit/c2c912024f22d498e343bbd52e57a65f3fd4... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2020