November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3231) [DMN Designer] Stack overflow when undo'ing Name change in top-level grid

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3231?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-3231: ----------------------------------- Sprint: 2018 Week 45-47 > [DMN Designer] Stack overflow when undo'ing Name change in top-level grid > -------------------------------------------------------------------------- > > Key: DROOLS-3231 > URL: https://issues.jboss.org/browse/DROOLS-3231 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > > When undo'ing the change to the {{Name}} on a top-level grid a stack-overflow occurs. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4196) SNICombinedWithALPNTestCase fails with IBM JDK

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4196?page=com.atlassian.jira.plugi... ] Jan Stourac updated WFCORE-4196: -------------------------------- Description: SNICombinedWithALPNTestCase added with WFCORE-3873 does not conform with IBM JDK key algorithm name. This needs to be fixed. Also as IBM JDK 8 and lower does not contain ALPN implementation and neither the ALPN-hack work there (it works only with Oracle JDK and Open JDK as it depends on JDK internals) we would have to provide ALPN in such situation somehow. We can either use Jetty ALPN implementation or wildfly-openssl using OpenSSL libraries. Both variants would bring unwanted difficulties with running this testsuite in our environment. Let's skip these tests for IBM JDK less than version 9. With newer IBM JDK version, there will probably be ALPN already part of JDK, so we can execute it then. was: SNICombinedWithALPNTestCase does not conform with IBM JDK key algorithm name. This needs to be fixed. Also as IBM JDK 8 and lower does not contain ALPN implementation and neither the ALPN-hack work there (it works only with Oracle JDK and Open JDK as it depends on JDK internals) we would have to provide ALPN in such situation somehow. We can either use Jetty ALPN implementation or wildfly-openssl using OpenSSL libraries. Both variants would bring unwanted difficulties with running this testsuite in our environment. Let's skip these tests for IBM JDK less than version 9. With newer IBM JDK version, there will probably be ALPN already part of JDK, so we can execute it then. > SNICombinedWithALPNTestCase fails with IBM JDK > ---------------------------------------------- > > Key: WFCORE-4196 > URL: https://issues.jboss.org/browse/WFCORE-4196 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Stourac > Assignee: Jan Stourac > Priority: Major > > SNICombinedWithALPNTestCase added with WFCORE-3873 does not conform with IBM JDK key algorithm name. This needs to be fixed. > Also as IBM JDK 8 and lower does not contain ALPN implementation and neither the ALPN-hack work there (it works only with Oracle JDK and Open JDK as it depends on JDK internals) we would have to provide ALPN in such situation somehow. We can either use Jetty ALPN implementation or wildfly-openssl using OpenSSL libraries. Both variants would bring unwanted difficulties with running this testsuite in our environment. > Let's skip these tests for IBM JDK less than version 9. With newer IBM JDK version, there will probably be ALPN already part of JDK, so we can execute it then. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4196) SNICombinedWithALPNTestCase fails with IBM JDK

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4196?page=com.atlassian.jira.plugi... ] Jan Stourac updated WFCORE-4196: -------------------------------- Component/s: Security > SNICombinedWithALPNTestCase fails with IBM JDK > ---------------------------------------------- > > Key: WFCORE-4196 > URL: https://issues.jboss.org/browse/WFCORE-4196 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Reporter: Jan Stourac > Assignee: Jan Stourac > Priority: Major > > SNICombinedWithALPNTestCase added with WFCORE-3873 does not conform with IBM JDK key algorithm name. This needs to be fixed. > Also as IBM JDK 8 and lower does not contain ALPN implementation and neither the ALPN-hack work there (it works only with Oracle JDK and Open JDK as it depends on JDK internals) we would have to provide ALPN in such situation somehow. We can either use Jetty ALPN implementation or wildfly-openssl using OpenSSL libraries. Both variants would bring unwanted difficulties with running this testsuite in our environment. > Let's skip these tests for IBM JDK less than version 9. With newer IBM JDK version, there will probably be ALPN already part of JDK, so we can execute it then. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4196) SNICombinedWithALPNTestCase fails with IBM JDK

by Jan Stourac (Jira)

Jan Stourac created WFCORE-4196: ----------------------------------- Summary: SNICombinedWithALPNTestCase fails with IBM JDK Key: WFCORE-4196 URL: https://issues.jboss.org/browse/WFCORE-4196 Project: WildFly Core Issue Type: Bug Components: Test Suite Reporter: Jan Stourac Assignee: Jan Stourac SNICombinedWithALPNTestCase does not conform with IBM JDK key algorithm name. This needs to be fixed. Also as IBM JDK 8 and lower does not contain ALPN implementation and neither the ALPN-hack work there (it works only with Oracle JDK and Open JDK as it depends on JDK internals) we would have to provide ALPN in such situation somehow. We can either use Jetty ALPN implementation or wildfly-openssl using OpenSSL libraries. Both variants would bring unwanted difficulties with running this testsuite in our environment. Let's skip these tests for IBM JDK less than version 9. With newer IBM JDK version, there will probably be ALPN already part of JDK, so we can execute it then. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3230) DMN - Generating sources for executable model uses wrong paths on Windows

by Tibor Zimányi (Jira)

Tibor Zimányi created DROOLS-3230: ------------------------------------- Summary: DMN - Generating sources for executable model uses wrong paths on Windows Key: DROOLS-3230 URL: https://issues.jboss.org/browse/DROOLS-3230 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.13.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi This change [1] introduced the use of Path.toString() method, which returns OS dependent path string. However MemoryFileSystem works just with "/" path separators, so the compilation cannot find generated source files on Windows, because the paths contain "\" instead of "/". [1] https://github.com/kiegroup/drools/pull/2117/files#diff-10fdf1615822ed09a... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3230) DMN - Generating sources for executable model uses wrong paths on Windows

by Tibor Zimányi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3230?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-3230: ---------------------------------- Story Points: 2 > DMN - Generating sources for executable model uses wrong paths on Windows > ------------------------------------------------------------------------- > > Key: DROOLS-3230 > URL: https://issues.jboss.org/browse/DROOLS-3230 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.13.0.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Priority: Critical > > This change [1] introduced the use of Path.toString() method, which returns OS dependent path string. However MemoryFileSystem works just with "/" path separators, so the compilation cannot find generated source files on Windows, because the paths contain "\" instead of "/". > [1] https://github.com/kiegroup/drools/pull/2117/files#diff-10fdf1615822ed09a... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1663) BC FIPS, Management Interface, ELY04001: No algorithm found matching TLS/SSL protocol selection criteria

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/ELY-1663?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1663: ----------------------------------- [~fjuma] I hit it again. So case is chasing us again? Does it mean case fix [1] is not 100% complete and something more is needed? [1] https://github.com/wildfly-security/wildfly-elytron/pull/1164 > BC FIPS, Management Interface, ELY04001: No algorithm found matching TLS/SSL protocol selection criteria > -------------------------------------------------------------------------------------------------------- > > Key: ELY-1663 > URL: https://issues.jboss.org/browse/ELY-1663 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.6.0.Final > Reporter: Martin Choma > Priority: Critical > > Rarely 1:30 it happens there occures error accessing http management interface secured with TLS with BC FIPS > {code} > Operation {"operation" => "add","address" => [("subsystem" => "elytron"),("server-ssl-context" => "test-server-ssl-context")],"key-manager" => "key-manager-name_test-server-ssl-context","cipher-suite-filter" => "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256","trust-manager" => "trust-manager-name_test-server-ssl-context","protocols" => ["TLSv1.2"],"need-client-auth" => true} failed: {"outcome" => "failed","failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.test-server-ssl-context" => "java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria > Caused by: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria"}},"rolled-back" => true} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.ssl-context.test-server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.test-server-ssl-context: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria > at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:982) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.security.NoSuchAlgorithmException: ELY04001: No algorithm found matching TLS/SSL protocol selection criteria > at org.wildfly.security.ssl.SSLUtils.lambda$createSslContextFactory$1(SSLUtils.java:130) > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:340) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53) > at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:980) > ... 9 more > {code} > Some facts > * It happens only on management interface BC FIPS TLS tests > * It does not occur on Undertow secured with BC FIPS > * Previously there was issue with similar error but that happened everywhere https://issues.jboss.org/browse/ELY-1618 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3219) [DMN Designer] Nodes can not be added once autolayout applied

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3219?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3219: -------------------------------- Description: The nodes can't be added to the DMN diagram, that was imported into workbench and didn't include layout information. h2. Acceptance test - Steps to reproduce fixed (/) - Autolayout is applied when [asset|https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-core...] upleaded (/) was: The nodes can't be added to the DMN diagram, that was imported into workbench and didn't include layout information. h2. Acceptance test - Steps to reproduce fixed - Autolayout is applied when [asset|https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-core...] upleaded > [DMN Designer] Nodes can not be added once autolayout applied > ------------------------------------------------------------- > > Key: DROOLS-3219 > URL: https://issues.jboss.org/browse/DROOLS-3219 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > Attachments: 2018-10-31 2.34.55 PM.gif, DMCommunity Challenge - March 2017.dmn > > > The nodes can't be added to the DMN diagram, that was imported into workbench and didn't include layout information. > h2. Acceptance test > - Steps to reproduce fixed (/) > - Autolayout is applied when [asset|https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-core...] upleaded (/) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2890) [DMN Designer] DMNDiagram properties

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-2890?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-2890: ------------------------------------- [~manstis] thanks! > [DMN Designer] DMNDiagram properties > ------------------------------------ > > Key: DROOLS-2890 > URL: https://issues.jboss.org/browse/DROOLS-2890 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.10.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > Fix For: 7.14.0.Final > > > The {{DMNDiagram}} node needs to expose the following properties (from [~tirelli] on DROOLS-[2870|https://issues.jboss.org/browse/DROOLS-2870?focusedCommentId...) > {quote} > The Definitions properties that I think we need to expose are: > * Id (probably read only) > * name (needs to be editable; can default to the file name but should remain editable) > * namespace > * Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above. > {quote} > h2. Manual acceptance test > h3. 1.1 file > - Import model with namespace (/) > - Import model without namespace (/) > h3. 1.2 file > - B&D new model, non default namespace (/) > - Import model with namespace (/) > - Import model without namespace (/) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3227) [DMN Designer] Decision table output data type is not stored if decision table is generated according to input data

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-3227?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-3227: ----------------------------------- Story Points: 5 Sprint: 2018 Week 45-47 > [DMN Designer] Decision table output data type is not stored if decision table is generated according to input data > ------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3227 > URL: https://issues.jboss.org/browse/DROOLS-3227 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > Attachments: auto.dmn > > > The decision table output column data type is not stored, if the decision table was generated according to some input data. > An example of such table is attached [^auto.dmn] . This table was created in steps below: > - Create new DMN diagram > - Add an Input Data node : *applicant* > - Add a Decision node: *applicant score* > - Connect them > - Define new data type: *tApplicant*. > -- lang:string (Constraints: "c", "java") > -- open source: boolean > - Set *applicant* node data type as *tApplicant* > - Set *applicant score* node data type as *number* > - Open expression editor for *applicant score* node > - Set its top level expression as Decision Table > - Save and download DMN model > - It will be like the attached > {code:xml} > <dmn:output id="_E6C7E5E6-45C5-4FC2-A37B-69806046893F" name="output-1" typeRef="string"> > <dmn:outputValues id="_B473BAB4-521D-4FD9-88BC-C28CD497F03A"> > <dmn:text></dmn:text> > </dmn:outputValues> > <dmn:defaultOutputEntry id="_85BF133E-380C-4F0E-9E2A-0C5C6493F6B4" typeRef="string"> > <dmn:text></dmn:text> > </dmn:defaultOutputEntry> > </dmn:output> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 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 November 2018