April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4932) Reading of identity from security domain causes NPE

by Diana Vilkolakova (Jira)

Diana Vilkolakova created WFCORE-4932: ----------------------------------------- Summary: Reading of identity from security domain causes NPE Key: WFCORE-4932 URL: https://issues.redhat.com/browse/WFCORE-4932 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Diana Vilkolakova Assignee: Diana Vilkolakova Security domain in the elytron subsystem has operation `read-identity`. Description of this opearation is the following: `Reads an identity from a security domain if it exists.` However, this operation causes NPE when called on the security domain backed by the filesystem realm (see steps to reproduce) or jdbc realm. This issue is to address that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (LOGMGR-263) Logger Lookup is much slower as with JDK 8

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/LOGMGR-263?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated LOGMGR-263: --------------------------------- Labels: downstream_dependency (was: ) > Logger Lookup is much slower as with JDK 8 > ------------------------------------------ > > Key: LOGMGR-263 > URL: https://issues.redhat.com/browse/LOGMGR-263 > Project: JBoss Log Manager > Issue Type: Bug > Environment: WildFly 17, OpenJDK 11 > Reporter: Andreas Liebscher > Assignee: James Perkins > Priority: Critical > Labels: downstream_dependency > Fix For: 2.1.15.Final, 2.2.0.Final, 3.0.0.Final > > Attachments: ClassInEar.java, LogContextCacher.java, getlogger-stack.txt, grafik1570016303722 (1).png, grafik1570016303722.png, grafik1570016791285.png, logger-demo.war, responsetimes.png > > > During upgrading a Java EE application from WildFly 13 with JDK 8 to WildFly 17 with JDK 11 we had a serious performance issue. We identified the usage of the logging framework SLF4J with the pattern `Logger log = LoggerFactory.getLogger(XXX.class)` was the reason when a lot of calls to `getLogger` occur in parallel. As workaround we added `static` to some code hotspots to get back the performance we were used to. Also WildFly 13 with JDK 8 got a performance improvement with the added `static` keyword. > Please check the VisualVM output as prove of JDKSpecific got slower: -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4930) Upgrade jboss-logmanager from 2.1.14.Final to 2.1.15.Final

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4930?page=com.atlassian.jira.plug... ] Ilia Vassilev updated WFCORE-4930: ---------------------------------- Labels: downstream_dependency (was: ) > Upgrade jboss-logmanager from 2.1.14.Final to 2.1.15.Final > ---------------------------------------------------------- > > Key: WFCORE-4930 > URL: https://issues.redhat.com/browse/WFCORE-4930 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Labels: downstream_dependency > > Upgrade {{org.jboss.logmanager:jboss-logmanager}} to 2.1.15.Final. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13388) Undertow subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13388: ------------------------------------- Summary: Undertow subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it Key: WFLY-13388 URL: https://issues.redhat.com/browse/WFLY-13388 Project: WildFly Issue Type: Bug Reporter: Tomasz Adamski Assignee: Tomasz Adamski Undertow has 'enable-jacc' attribute which, if true, result in the code doing a service dep using the org.wildfly.security.jacc-policy capability. But there's no registration of a requirement for that capability, so if it were removed (which requires reload) the inconsistent model would not be detected and a subsequent reboot/restart would fail. This can't be fixed until WFCORE-3354 is, because right now that capability isn't registered either! Fixing this isn't as simple as recording this as a fixed requirement of the relevant ejb/undertow capability, as it's only a requirement if the attribute value is 'true'. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9440) EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-9440?page=com.atlassian.jira.plugin... ] Tomasz Adamski updated WFLY-9440: --------------------------------- Description: EJB has 'enable-jacc' attribute which, if true, result in the code doing a service dep using the org.wildfly.security.jacc-policy capability. But there's no registration of a requirement for that capability, so if it were removed (which requires reload) the inconsistent model would not be detected and a subsequent reboot/restart would fail. This can't be fixed until WFCORE-3354 is, because right now that capability isn't registered either! Fixing this isn't as simple as recording this as a fixed requirement of the relevant ejb/undertow capability, as it's only a requirement if the attribute value is 'true'. was: Both EJB and Undertow have 'enable-jacc' attributes which, if true, result in the code doing a service dep using the org.wildfly.security.jacc-policy capability. But there's no registration of a requirement for that capability, so if it were removed (which requires reload) the inconsistent model would not be detected and a subsequent reboot/restart would fail. This can't be fixed until WFCORE-3354 is, because right now that capability isn't registered either! Fixing this isn't as simple as recording this as a fixed requirement of the relevant ejb/undertow capability, as it's only a requirement if the attribute value is 'true'. > EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-9440 > URL: https://issues.redhat.com/browse/WFLY-9440 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Brian Stansberry > Assignee: Tomasz Adamski > Priority: Major > > EJB has 'enable-jacc' attribute which, if true, result in the code doing a service dep using the org.wildfly.security.jacc-policy capability. But there's no registration of a requirement for that capability, so if it were removed (which requires reload) the inconsistent model would not be detected and a subsequent reboot/restart would fail. > This can't be fixed until WFCORE-3354 is, because right now that capability isn't registered either! > Fixing this isn't as simple as recording this as a fixed requirement of the relevant ejb/undertow capability, as it's only a requirement if the attribute value is 'true'. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9440) EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-9440?page=com.atlassian.jira.plugin... ] Tomasz Adamski updated WFLY-9440: --------------------------------- Summary: EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it (was: EJB and Undertow subsystems use org.wildfly.security.jacc-policy capability without registering a requirement for it) > EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-9440 > URL: https://issues.redhat.com/browse/WFLY-9440 > Project: WildFly > Issue Type: Bug > Components: EJB, Web (Undertow) > Reporter: Brian Stansberry > Assignee: Tomasz Adamski > Priority: Major > > Both EJB and Undertow have 'enable-jacc' attributes which, if true, result in the code doing a service dep using the org.wildfly.security.jacc-policy capability. But there's no registration of a requirement for that capability, so if it were removed (which requires reload) the inconsistent model would not be detected and a subsequent reboot/restart would fail. > This can't be fixed until WFCORE-3354 is, because right now that capability isn't registered either! > Fixing this isn't as simple as recording this as a fixed requirement of the relevant ejb/undertow capability, as it's only a requirement if the attribute value is 'true'. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9440) EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it

by Tomasz Adamski (Jira)

[ https://issues.redhat.com/browse/WFLY-9440?page=com.atlassian.jira.plugin... ] Tomasz Adamski updated WFLY-9440: --------------------------------- Component/s: (was: Web (Undertow)) > EJB subsystem use org.wildfly.security.jacc-policy capability without registering a requirement for it > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-9440 > URL: https://issues.redhat.com/browse/WFLY-9440 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Brian Stansberry > Assignee: Tomasz Adamski > Priority: Major > > Both EJB and Undertow have 'enable-jacc' attributes which, if true, result in the code doing a service dep using the org.wildfly.security.jacc-policy capability. But there's no registration of a requirement for that capability, so if it were removed (which requires reload) the inconsistent model would not be detected and a subsequent reboot/restart would fail. > This can't be fixed until WFCORE-3354 is, because right now that capability isn't registered either! > Fixing this isn't as simple as recording this as a fixed requirement of the relevant ejb/undertow capability, as it's only a requirement if the attribute value is 'true'. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5166) Implement test module for tree model in new PMML implementation

by Jiri Petrlik (Jira)

[ https://issues.redhat.com/browse/DROOLS-5166?page=com.atlassian.jira.plug... ] Jiri Petrlik commented on DROOLS-5166: -------------------------------------- PR with tests and implementation was merged. > Implement test module for tree model in new PMML implementation > --------------------------------------------------------------- > > Key: DROOLS-5166 > URL: https://issues.redhat.com/browse/DROOLS-5166 > Project: Drools > Issue Type: Task > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Priority: Major > Labels: TrustyAI > > Implement test module for PMML tree model in new PMML implementation. This module should contain tests which simultaneously test compiler and evaluator. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2469) GossipRouter: make GraalVM-compliant

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2469?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2469. ---------------------------- Resolution: Done > GossipRouter: make GraalVM-compliant > ------------------------------------ > > Key: JGRP-2469 > URL: https://issues.redhat.com/browse/JGRP-2469 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Alpha5, 4.2.4 > > > Currently, GossipRouter starts threads in the constructor. This prohibits it to run under GraalVM as a native image, as threads cannot be started at build time. > Create a separate method {{init()}}, which is called after the constructor and after all attributes have been set, but before {{start()}}. > Alternative: use a builder: > {code:java} > router=GossipRouter.builder().setXX().build(); // creates server > router.start(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2469) GossipRouter: make GraalVM-compliant

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2469?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2469: --------------------------- Fix Version/s: 4.2.4 > GossipRouter: make GraalVM-compliant > ------------------------------------ > > Key: JGRP-2469 > URL: https://issues.redhat.com/browse/JGRP-2469 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0.0.Alpha5, 4.2.4 > > > Currently, GossipRouter starts threads in the constructor. This prohibits it to run under GraalVM as a native image, as threads cannot be started at build time. > Create a separate method {{init()}}, which is called after the constructor and after all attributes have been set, but before {{start()}}. > Alternative: use a builder: > {code:java} > router=GossipRouter.builder().setXX().build(); // creates server > router.start(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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