October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5700) Implement range index in Alpha Network Compiler

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5700?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5700: -------------------------------------- Sprint: 2020 Week 43-45 (from Okt 19) > Implement range index in Alpha Network Compiler > ----------------------------------------------- > > Key: DROOLS-5700 > URL: https://issues.redhat.com/browse/DROOLS-5700 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.44.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > As of DROOLS-5647, I get alphaNodes from the rangeIndexMap and simply pass them to ObjectTypeNodeParser.traverseSink() just like 'otherSinks'. It means at the moment, ANC doesn't benefit from the range index. > This JIRA is to implement range index in the generated code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5700) Implement range index in Alpha Network Compiler

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5700: ----------------------------------------- Summary: Implement range index in Alpha Network Compiler Key: DROOLS-5700 URL: https://issues.redhat.com/browse/DROOLS-5700 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.44.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi As of DROOLS-5647, I get alphaNodes from the rangeIndexMap and simply pass them to ObjectTypeNodeParser.traverseSink() just like 'otherSinks'. It means at the moment, ANC doesn't benefit from the range index. This JIRA is to implement range index in the generated code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5687) NullPointerException on second consecutive declared type update

by Matteo Casalino (Jira)

[ https://issues.redhat.com/browse/DROOLS-5687?page=com.atlassian.jira.plug... ] Matteo Casalino updated DROOLS-5687: ------------------------------------ Attachment: npe-consecutives-declare-update-skip-kiebase-init.zip > NullPointerException on second consecutive declared type update > --------------------------------------------------------------- > > Key: DROOLS-5687 > URL: https://issues.redhat.com/browse/DROOLS-5687 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.43.0.Final > Reporter: Matteo Casalino > Assignee: Mario Fusco > Priority: Major > Attachments: npe-consecutives-declare-update-skip-kiebase-init.zip, npe-consecutives-declare-update.zip > > > When updating a {{KieContainer}} with {{updateToVersion}} with a change in a declared type two consecutive times, a {{NullPointerException}} is raised. > Minimal example DRL triggering the issue (notice at least two declared types are needed): > {noformat} > declare FactType1 > x : int > end > declare FactType2 > y : int > end > {noformat} > first update: > {noformat} > declare FactType1 > x : int > z : int > end > declare FactType2 > y : int > end > {noformat} > second update: > {noformat} > declare FactType1 > x : int > z : int > w : int > end > declare FactType2 > y : int > end > {noformat} > The second update will raise the following exception: > {noformat} > java.lang.NullPointerException > at org.drools.compiler.kie.util.ChangeSetBuilder.build(ChangeSetBuilder.java:106) > at org.drools.compiler.kie.builder.impl.InternalKieModule.getChanges(InternalKieModule.java:132) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:241) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:237) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:195) > at org.example.reproducer.KjarUpdateTest.update(KjarUpdateTest.java:37) > at org.example.reproducer.KjarUpdateTest.testConsecutiveUpdates(KjarUpdateTest.java:48) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5206) Create a separated module for InMemory Compiler

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5206?page=com.atlassian.jira.plug... ] Luca Molteni resolved DROOLS-5206. ---------------------------------- Resolution: Done > Create a separated module for InMemory Compiler > ----------------------------------------------- > > Key: DROOLS-5206 > URL: https://issues.redhat.com/browse/DROOLS-5206 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > > Currently we do in-memory compilation and loading in different places. Soon we'll have it in > - Drools Executable Model > - PMML > - DMN > By creating a new external module that does exactly that (in-memory compile and load it in the class loader) without being coupled to Drools in anyway we can reuse it. > Related to https://issues.redhat.com/browse/DROOLS-5130 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5699) Executable model should have the Alpha Newtork Compiled in the KJar

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5699?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5699: --------------------------------- Sprint: 2020 Week 40-42 (from Sep 28) > Executable model should have the Alpha Newtork Compiled in the KJar > ------------------------------------------------------------------- > > Key: DROOLS-5699 > URL: https://issues.redhat.com/browse/DROOLS-5699 > Project: Drools > Issue Type: Enhancement > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Minor > > When using the Alpha Network Compiler with the executable model, the source code for the class is generated and compiled at startup time using the InMemoryCompiler. > By generating the compiled Alpha Network in the kie-maven-plugin, we could simply load it from the classloader -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5699) Executable model should have the Alpha Newtork Compiled in the KJar

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5699?page=com.atlassian.jira.plug... ] Luca Molteni updated DROOLS-5699: --------------------------------- Priority: Minor (was: Major) > Executable model should have the Alpha Newtork Compiled in the KJar > ------------------------------------------------------------------- > > Key: DROOLS-5699 > URL: https://issues.redhat.com/browse/DROOLS-5699 > Project: Drools > Issue Type: Enhancement > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Minor > > When using the Alpha Network Compiler with the executable model, the source code for the class is generated and compiled at startup time using the InMemoryCompiler. > By generating the compiled Alpha Network in the kie-maven-plugin, we could simply load it from the classloader -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5699) Executable model should have the Alpha Newtork Compiled in the KJar

by Luca Molteni (Jira)

Luca Molteni created DROOLS-5699: ------------------------------------ Summary: Executable model should have the Alpha Newtork Compiled in the KJar Key: DROOLS-5699 URL: https://issues.redhat.com/browse/DROOLS-5699 Project: Drools Issue Type: Enhancement Components: executable model Reporter: Luca Molteni Assignee: Luca Molteni When using the Alpha Network Compiler with the executable model, the source code for the class is generated and compiled at startup time using the InMemoryCompiler. By generating the compiled Alpha Network in the kie-maven-plugin, we could simply load it from the classloader -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13924: ------------------------------------ Steps to Reproduce: Info about JDK used: {code} $ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode) {code} h2. Legacy Security Realm # unzip the WildFly # start the server with proper JDK {code} JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh {code} # wait till server boots up and perform an HTTP request (note that curl with HTTP2 support has to be used, otherwise use different client) {code} curl -k https://localhost:8443 -vvv >/dev/null {code} # see that HTTP/1.1 is used only; there is also this message in the output {quote} * ALPN, server did not agree to a protocol {quote} Now workaround: # unzip the WildFly # start the server with proper JDK and property from UNDERTOW-1726 {code} JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh -Dio.undertow.protocols.alpn.jdk8 {code} # wait till server boots up and perform an HTTP request {code} curl -k https://localhost:8443 -vvv >/dev/null {code} # see that HTTP/2 is used successfully now h2. Unwrapped Elytron Configuration This step needs to be run AFTER the first step so the default self signed certificate is pre-generated. Execute the following CLI commands to switch to an Elytron SSLContext: {code} /subsystem=elytron/key-store=test:add(relative-to=jboss.server.config.dir, path=application.keystore, credential-reference={clear-text=password}) /subsystem=elytron/key-manager=test:add(key-store=test, credential-reference={clear-text=password}) /subsystem=elytron/server-ssl-context=test:add(key-manager=test) batch /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=test) run-batch {code} The same curl command can be used to test the establishment of a HTTPS connection. Using the system property -Dio.undertow.protocols.alpn.jdk8 again restores the ability to use ALPN. h2. Wrapped Elytron Configuration _It was always preferred that the Elytron subsystem would wrap the SSLContext to prevent against unintended modification but we had to drop to unwrapping to support the JDK 8 hack needed for ALPN._ This third test should be executed after the previous test as it is a continuation of the configuration. Execute the following CLI to ensure the SSLContext is wrapped: {code} /subsystem=elytron/server-ssl-context=test:write-attribute(name=wrap, value=true) {code} If the server is restarted with or without the system property ALPN is not available. was: Info about JDK used: {code} $ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode) {code} # unzip the WildFly # start the server with proper JDK {code} JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh {code} # wait till server boots up and perform an HTTP request (note that curl with HTTP2 support has to be used, otherwise use different client) {code} curl -k https://localhost:8443 -vvv >/dev/null {code} # see that HTTP/1.1 is used only; there is also this message in the output {quote} * ALPN, server did not agree to a protocol {quote} Now workaround: # unzip the WildFly # start the server with proper JDK and property from UNDERTOW-1726 {code} JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh -Dio.undertow.protocols.alpn.jdk8 {code} # wait till server boots up and perform an HTTP request {code} curl -k https://localhost:8443 -vvv >/dev/null {code} # see that HTTP/2 is used successfully now > HTTP2 is not working with Oracle JDK8 u261 > ------------------------------------------ > > Key: WFLY-13924 > URL: https://issues.redhat.com/browse/WFLY-13924 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1 > Reporter: Jan Stourac > Assignee: Flavia Rainone > Priority: Blocker > Fix For: 21.0.0.Final > > > There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1. > There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions. > This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726. > There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed). > *What is the issue here:* > This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1226) Remove params for HUB, TAG, IMAGE from upstream/downstream where possible

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1226?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1226. ---------------------------------- Resolution: Done > Remove params for HUB, TAG, IMAGE from upstream/downstream where possible > ------------------------------------------------------------------------- > > Key: SWSQE-1226 > URL: https://issues.redhat.com/browse/SWSQE-1226 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > Labels: infrastructure > > We are always using OLM for downstream job so there is no sense in using HUB/IMAGE/TAG parameters. > For upstream job we probably don't need it for istio and jaeger -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13942) Remove the modules supporting Hibernate ORM 4.1 and 4.3

by Sanne Grinovero (Jira)

[ https://issues.redhat.com/browse/WFLY-13942?page=com.atlassian.jira.plugi... ] Sanne Grinovero updated WFLY-13942: ----------------------------------- Summary: Remove the modules supporting Hibernate ORM 4.1 and 4.3 (was: Drop support for Hibernate 4 modules) > Remove the modules supporting Hibernate ORM 4.1 and 4.3 > ------------------------------------------------------- > > Key: WFLY-13942 > URL: https://issues.redhat.com/browse/WFLY-13942 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Major > > The modules for Hibernate5-legacy have already been removed (WFLY-13819), we should cleanup the support for Hibernate 4 as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 October 2020