January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12975) JWT is rejected if signature matching public key is not first in JWK set

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12975?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-294 to WFLY-12975: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12975 (was: WFWIP-294) Component/s: MP JWT (was: MP JWT) > JWT is rejected if signature matching public key is not first in JWK set > ------------------------------------------------------------------------ > > Key: WFLY-12975 > URL: https://issues.redhat.com/browse/WFLY-12975 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > Attachments: jwks.json, jwt.base64 > > > When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array. > This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property. > Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair. > This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states: > In section 9.2.3: > {quote} > If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature. > {quote} > In section 4.1: > {quote} > kid - This JOSE header parameter is a hint indicating which key was used to secure the JWT. RFC7515, Section-4.1.4 > {quote} > And the RFC7515, Section-4.1.4 states: > {quote} > When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12974) Default cache configurations for local/passivating caches are overly restrictive

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12974: ----------------------------------- Summary: Default cache configurations for local/passivating caches are overly restrictive Key: WFLY-12974 URL: https://issues.redhat.com/browse/WFLY-12974 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro For local caches with either a passivating, non-shared cache store; or without a cache store, the use of transactions overly restricts concurrency and limits performance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split detection 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: ---------------------------------- Fix Version/s: 20.0.0.Beta1 > Cannot customize split detection 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 > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12969) Include Openshift Instructions in EAP non-CD Quickstarts READMEs

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-12969?page=com.atlassian.jira.plugi... ] Eduardo Martins updated WFLY-12969: ----------------------------------- Summary: Include Openshift Instructions in EAP non-CD Quickstarts READMEs (was: Include openshift instructions in baremetal Quickstarts docs) > Include Openshift Instructions in EAP non-CD Quickstarts READMEs > ---------------------------------------------------------------- > > Key: WFLY-12969 > URL: https://issues.redhat.com/browse/WFLY-12969 > Project: WildFly > Issue Type: Feature Request > Components: Quickstarts > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > > Currently QS readmes include the openshift instructions only for CD releases. QS that run on Openshift (those included in CD releases) should contain openshift instructions for non-CD releases too, as the openshift image is released. > For example helloworld QS, which is also included in CD release: > https://raw.githubusercontent.com/wildfly/quickstart/master/helloworld/RE... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-10199?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-10199: --------------------------------- Fix Version/s: 13.0.0.Final > Using jboss-modules loading outside WildFly 12 is broken > -------------------------------------------------------- > > Key: WFLY-10199 > URL: https://issues.redhat.com/browse/WFLY-10199 > Project: WildFly > Issue Type: Bug > Affects Versions: 12.0.0.Final > Reporter: Martin Perina > Assignee: David Lloyd > Priority: Major > Fix For: 13.0.0.Final > > > oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11: > {code} > export JAVA_MODULEPATH="<PATH TO OUR MODULES>" > exec "${JAVA_HOME}/bin/java" \ > -jar "${JBOSS_HOME}/jboss-modules.jar" \ > -dependencies org.ovirt.engine.core.tools \ > -class org.ovirt.engine.core.cryptotool.Main \ > "$@" > {code} > where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool. > When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception: > {code} > Exception in thread "main" java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:460) > at java.util.Properties.setProperty(Properties.java:166) > at java.lang.System.setProperty(System.java:796) > at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40) > at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.modules.Main.main(Main.java:390) > {code} > When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error: > {code} > org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools > at org.jboss.modules.Module.addPaths(Module.java:1221) > at org.jboss.modules.Module.link(Module.java:1577) > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296) > at org.jboss.modules.Main.main(Main.java:426) > {code} > I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions? > Thanks > Martin -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4920: -------------------------------- Description: If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. [1] !Screenshot from 2020-01-08 14-14-05.png|thumbnail! h3. Acceptance criteria https://github.com/jboss-integration/bxms-qe-tests/pull/3048 was: If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. [1] !Screenshot from 2020-01-08 14-14-05.png|thumbnail! > Scenario simulation for DMN with collections throws en error > ------------------------------------------------------------ > > Key: DROOLS-4920 > URL: https://issues.redhat.com/browse/DROOLS-4920 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.31.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. > [1] > !Screenshot from 2020-01-08 14-14-05.png|thumbnail! > h3. Acceptance criteria > https://github.com/jboss-integration/bxms-qe-tests/pull/3048 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4920: ------------------------------------- Reproducer test https://github.com/jboss-integration/bxms-qe-tests/pull/3048 > Scenario simulation for DMN with collections throws en error > ------------------------------------------------------------ > > Key: DROOLS-4920 > URL: https://issues.redhat.com/browse/DROOLS-4920 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.31.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. > [1] > !Screenshot from 2020-01-08 14-14-05.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2430: -------------------------------- Compare the perf between sending local messages (e.g. over TCP or UDP) and sending remote messages (TUNNEL <-> GossipRouter) > GossipRouter: more efficient routing > ------------------------------------ > > Key: JGRP-2430 > URL: https://issues.redhat.com/browse/JGRP-2430 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address. > It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages. > Also look into routing of entire message _batches_. > Investigate whether this is possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12973) add micro profile artifacts to BOMs

by Stefano Maestri (Jira)

Stefano Maestri created WFLY-12973: -------------------------------------- Summary: add micro profile artifacts to BOMs Key: WFLY-12973 URL: https://issues.redhat.com/browse/WFLY-12973 Project: WildFly Issue Type: Enhancement Components: BOM Reporter: Stefano Maestri Assignee: Stefano Maestri Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3510) Decision table unable to generate rule for row with pattern without constraint

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-3510. --------------------------------- Resolution: Explained The behaviour of suppressing a pattern when it has no constraint cannot be changed also due to backward compatibility reason. It's easy to workaround this behaviour by adding a fake constraint always evaluating to true as I demonstrated in the attached DummyConstraints.xls file. > Decision table unable to generate rule for row with pattern without constraint > ------------------------------------------------------------------------------ > > Key: DROOLS-3510 > URL: https://issues.redhat.com/browse/DROOLS-3510 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.15.0.Final > Reporter: Andre Piwoni > Assignee: Mario Fusco > Priority: Minor > Attachments: DummyConstraint.xls, MissingConstraint.xls, failingDecisionTable.xlsx > > > When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment. > Expected rules to be generated: > {code:java} > rule "Test_1" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_2" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_3" > when > $factA:FactA() > $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(Y); > end > {code} > Also, there does not seem an alternative way to generate following rule using decision table: > {code:java} > rule "Test" > when > $factA:FactA($factsB: listOfFactsB) > $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1)) > then > insert(Y); > end > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 January 2020