April 2020 - jboss-jira - Jboss List Archives

[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)

4 years, 6 months

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)

4 years, 6 months

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)

4 years, 6 months

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)

4 years, 6 months

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)

4 years, 6 months

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)

4 years, 6 months

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 commented on JGRP-2469: -------------------------------- Didn't even need the {{init()}} method, as GossipRouter doesn't need any build time initialization; it starts up quickly enough (couple of millis), plus this way, we can have all of the command line options: {noformat} [belasmac] /Users/bela$ gossiprouter setrlimit to increase file descriptor limit failed, errno 22 GossipRouter started in 1 ms listening on 0.0.0.0:12001 {noformat} > 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 > > > 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)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13387) Expose Jaeger Client Metrics

by Tobias Stadler (Jira)

Tobias Stadler created WFLY-13387: ------------------------------------- Summary: Expose Jaeger Client Metrics Key: WFLY-13387 URL: https://issues.redhat.com/browse/WFLY-13387 Project: WildFly Issue Type: Feature Request Components: MP Metrics, MP OpenTracing Reporter: Tobias Stadler Assignee: Jeff Mesnil I would be nice, if the internal jaeger client metrics could be exposed via mp metrics endpoint. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4915) Tighten up the dependency tree of subsystem-test

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFCORE-4915?page=com.atlassian.jira.plug... ] Kabir Khan commented on WFCORE-4915: ------------------------------------ [~brian.stansberry] I think for the transformer tests (if we need those for) kind of rely on transitive dependencies behind the scenes for the dependencies of the legacy controller. But if I remember correctly (I've not looked) those are more added at runtime stuff. So I think it is possible to trim the tree for what is on the main dependency classpath. > Tighten up the dependency tree of subsystem-test > ------------------------------------------------ > > Key: WFCORE-4915 > URL: https://issues.redhat.com/browse/WFCORE-4915 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > In general I'd like to tighten (aka eliminate) up the use of transitive dependencies when various WildFly and WildFly Core maven modules depend on each other. Things should be explicit so unwanted coupling cannot creep in. > The subsystem-test module is important in this regard as pretty much all extension modules depend on it's pom. So I want it and its children and its direct dependencies to only depend on other wf core modules directly, no transitive deps allowed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4915) Tighten up the dependency tree of subsystem-test

by Kabir Khan (Jira)

[ https://issues.redhat.com/browse/WFCORE-4915?page=com.atlassian.jira.plug... ] Kabir Khan edited comment on WFCORE-4915 at 4/17/20 6:51 AM: ------------------------------------------------------------- [~brian.stansberry] I think for the transformer tests (if we need those for MP) kind of rely on transitive dependencies behind the scenes for the dependencies of the legacy controller. But if I remember correctly (I've not looked) those are more added at runtime stuff. So I think it is possible to trim the tree for what is on the main dependency classpath. was (Author: kabirkhan): [~brian.stansberry] I think for the transformer tests (if we need those for) kind of rely on transitive dependencies behind the scenes for the dependencies of the legacy controller. But if I remember correctly (I've not looked) those are more added at runtime stuff. So I think it is possible to trim the tree for what is on the main dependency classpath. > Tighten up the dependency tree of subsystem-test > ------------------------------------------------ > > Key: WFCORE-4915 > URL: https://issues.redhat.com/browse/WFCORE-4915 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > In general I'd like to tighten (aka eliminate) up the use of transitive dependencies when various WildFly and WildFly Core maven modules depend on each other. Things should be explicit so unwanted coupling cannot creep in. > The subsystem-test module is important in this regard as pretty much all extension modules depend on it's pom. So I want it and its children and its direct dependencies to only depend on other wf core modules directly, no transitive deps allowed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020