May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5345) Class loading issue in Eclipse Equinox OSGi container

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5345?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5345: -------------------------------- Sprint: 2020 Week 22-24 (from May 25) (was: 2020 Week 19-21 (from May 4)) > Class loading issue in Eclipse Equinox OSGi container > ----------------------------------------------------- > > Key: DROOLS-5345 > URL: https://issues.redhat.com/browse/DROOLS-5345 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.37.0.Final > Reporter: Richard Schurig > Assignee: Mario Fusco > Priority: Major > > When using Drools inside an *Equinox* OSGi container (Oxygen, org.eclipse.osgi-3.12.0.v20170512-1932.jar) the logic inside {{org.drools.relective.classloader.ProjectClassLoader#isOsgiClassLoader}} does not work properly, i.e. the OSGi runtime is not detected. This leads to "The Eclipse JDT Core jar is not in the classpath" because the shaded and packed compiler classes cannot be found. > Cause of the problem seems to be the fact that the {{EquinoxClassLoader}} does not implement {{BundleReference}} directly *but so does its superclass*. I tried and patched {{ProjectClassLoader}} with the following snippet and this seems to work: > {code:java} > private static boolean isOsgiClassLoader(final ClassLoader cl) { > Class<?> clc = cl.getClass(); > while (clc != null && !clc.equals(ClassLoader.class)) { > if (Stream.of(clc.getInterfaces()).map(Class::getSimpleName).anyMatch(name -> name.equals("BundleReference"))) { > return true; > } > clc = clc.getSuperclass(); > } > return false; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5312) Investigate performance of Optaplanner's GroupBy

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5312?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5312: -------------------------------- Sprint: 2020 Week 22-24 (from May 25) (was: 2020 Week 19-21 (from May 4)) > Investigate performance of Optaplanner's GroupBy > ------------------------------------------------ > > Key: DROOLS-5312 > URL: https://issues.redhat.com/browse/DROOLS-5312 > Project: Drools > Issue Type: Task > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5364) Test scenario reports data type change during creation

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-5364?page=com.atlassian.jira.plug... ] Daniele Zonca reassigned DROOLS-5364: ------------------------------------- Assignee: Yeser Amer (was: Daniele Zonca) > Test scenario reports data type change during creation > ------------------------------------------------------ > > Key: DROOLS-5364 > URL: https://issues.redhat.com/browse/DROOLS-5364 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.38.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-05-25 08-04-44.png, sample_abcd.zip > > > There is warning about data type change even when a test scenario is just created. The spotted behavior would be expected if user is reopening a a scenario but not creating a new one. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5364) Test scenario reports data type change during creation

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5364: ----------------------------------- Summary: Test scenario reports data type change during creation Key: DROOLS-5364 URL: https://issues.redhat.com/browse/DROOLS-5364 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.38.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: Screenshot from 2020-05-25 08-04-44.png, sample_abcd.zip There is warning about data type change even when a test scenario is just created. The spotted behavior would be expected if user is reopening a a scenario but not creating a new one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1519) (var == $v) is faster than ($v == var) and scales much better: can they both be that fast?

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-1519?page=com.atlassian.jira.plug... ] Toshiya Kobayashi resolved DROOLS-1519. --------------------------------------- Fix Version/s: 7.35.0.Final Resolution: Done > (var == $v) is faster than ($v == var) and scales much better: can they both be that fast? > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1519 > URL: https://issues.redhat.com/browse/DROOLS-1519 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.35.0.Final > > > See: > http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... > The ($v == var) filters much later causing a scaling loss. > Investigate if drools can avoid that problem and make the slow one as fast as the fast one. > We don't want to have to rewrite all our rules to take advantage of this speedup and educate all our users to prefer one way over another, if and only if we can avoid it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1519) (var == $v) is faster than ($v == var) and scales much better: can they both be that fast?

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-1519?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-1519: ------------------------------------------- This is duplicated and fixed by DROOLS-4956 > (var == $v) is faster than ($v == var) and scales much better: can they both be that fast? > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1519 > URL: https://issues.redhat.com/browse/DROOLS-1519 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.35.0.Final > > > See: > http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... > The ($v == var) filters much later causing a scaling loss. > Investigate if drools can avoid that problem and make the slow one as fast as the fast one. > We don't want to have to rewrite all our rules to take advantage of this speedup and educate all our users to prefer one way over another, if and only if we can avoid it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1268) When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-1268?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-1268: ------------------------------------------- Thank you for the reply. Closing this JIRA. > When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1268 > URL: https://issues.redhat.com/browse/DROOLS-1268 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Nicolas Héron > Assignee: Maciej Swiderski > Priority: Major > Labels: OnBoarding > Attachments: logerror.txt, picture1.png > > > here is the JSON http://pastebin.com/t1CdHg9F > The logs are in the file attached logerror.txt > Going further > the error comes from class org.kie.remote.common.rest.KieRemoteHttpRequest line 1329 > and the error behind is "not enough data" > I put in attachement and it seems true -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1268) When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-1268?page=com.atlassian.jira.plug... ] Toshiya Kobayashi closed DROOLS-1268. ------------------------------------- Resolution: Out of Date > When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1268 > URL: https://issues.redhat.com/browse/DROOLS-1268 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Nicolas Héron > Assignee: Maciej Swiderski > Priority: Major > Labels: OnBoarding > Attachments: logerror.txt, picture1.png > > > here is the JSON http://pastebin.com/t1CdHg9F > The logs are in the file attached logerror.txt > Going further > the error comes from class org.kie.remote.common.rest.KieRemoteHttpRequest line 1329 > and the error behind is "not enough data" > I put in attachement and it seems true -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13510) [QE](7.3.z) [WFLY-12991] SunX509 TrustManagerFactory not available from Elytron tests on IBM jdk

by Peter Mackay (Jira)

Peter Mackay created WFLY-13510: ----------------------------------- Summary: [QE](7.3.z) [WFLY-12991] SunX509 TrustManagerFactory not available from Elytron tests on IBM jdk Key: WFLY-13510 URL: https://issues.redhat.com/browse/WFLY-13510 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Peter Mackay Assignee: Petr Kremensky Fix For: 19.0.0.Beta2, 19.0.0.Final On IBM JDK the following exception is thrown {noformat} Caused by: java.security.NoSuchAlgorithmException: SunX509 TrustManagerFactory not available at sun.security.jca.GetInstance.getInstance(GetInstance.java:171) at javax.net.ssl.TrustManagerFactory.getInstance(TrustManagerFactory.java:20) at org.wildfly.extension.elytron.SSLDefinitions$2.createTrustManagerFactory(SSLDefinitions.java:869) ... 11 more {noformat} from {noformat} org.wildfly.test.integration.elytron.audit.TLSSyslogAuditLogTestCase.testSuccessfulAuthAndPermissionCheck org.wildfly.test.integration.elytron.audit.TLSSyslogAuditLogTestCase.testFailedAuthWrongUser org.wildfly.test.integration.elytron.audit.TLSSyslogAuditLogTestCase.testFailedAuthEmptyPassword org.wildfly.test.integration.elytron.audit.TLSSyslogAuditLogTestCase.testFailedAuthWrongPassword org.wildfly.test.integration.elytron.audit.TLSSyslogAuditLogTestCase.testFailedPermissionCheck org.wildfly.test.integration.elytron.ssl.UndertowSslSecurityDomainTestCase.testForbidden org.wildfly.test.integration.elytron.ssl.UndertowSslSecurityDomainTestCase.testUnprotectedAccess org.wildfly.test.integration.elytron.ssl.UndertowSslSecurityDomainTestCase.testUntrustedCertificate org.wildfly.test.integration.elytron.ssl.UndertowSslSecurityDomainTestCase.testProtectedAccess org.wildfly.test.integration.elytron.ssl.UndertowTwoWaySslNeedClientAuthTestCase.testSendingTrustedClientCertificate org.wildfly.test.integration.elytron.ssl.UndertowTwoWaySslTestCase.testSendingNoClientCertificate org.wildfly.test.integration.elytron.ssl.UndertowTwoWaySslTestCase.testSendingNonTrustedClientCertificate org.wildfly.test.integration.elytron.ssl.UndertowTwoWaySslTestCase.testSendingTrustedClientCertificate {noformat} These need to use IBMX509 instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5363) DMN DT Analysis consolidate gap/overlap message reporting

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5363: -------------------------------------- Summary: DMN DT Analysis consolidate gap/overlap message reporting Key: DROOLS-5363 URL: https://issues.redhat.com/browse/DROOLS-5363 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Attachments: image-2020-05-23-15-21-16-425.png Consolidate accordingly to the following table: !image-2020-05-23-15-21-16-425.png! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

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 May 2020