March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2461) Credential-store attribute relative-to doesn't reference path as required

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2461?page=com.atlassian.jira.plugi... ] Ilia Vassilev commented on WFCORE-2461: --------------------------------------- credential-store doesn't define "path" so this is not relevant. (see JBEAP-6935 and JBEAP-8180) When researching the issue I noticed that we have description for property "elytron.credential-store.path" which should be removed. > Credential-store attribute relative-to doesn't reference path as required > ------------------------------------------------------------------------- > > Key: WFCORE-2461 > URL: https://issues.jboss.org/browse/WFCORE-2461 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ilia Vassilev > > Combination of {{path}} and {{relative-to}} attributes is common across all the elytron subsystem. All but one {{relative-to}} attributes list the "path" as required: > {code} > "relative-to" => { > "type" => STRING, > ... > "requires" => ["path"], > ... > } > {code} > The credential-store configuration doesn't define this dependency. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2544) Upgrade log4j-jboss-logmanager from 1.1.2.Final to 1.1.3.Final

by James Perkins (JIRA)

James Perkins created WFCORE-2544: ------------------------------------- Summary: Upgrade log4j-jboss-logmanager from 1.1.2.Final to 1.1.3.Final Key: WFCORE-2544 URL: https://issues.jboss.org/browse/WFCORE-2544 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins This includes a fix to allow the {{org.apache.log4j.helpers.Loader}} work with JEP-223. Also includes a fix to ensure the {{LoggingEvent.getThrowableInformation()}} returns {{null}} if the cause is {{null}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-121) Static initializer of class org.apache.log4j.helpers.Loader relies on obsolete java versioning scheme

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-121?page=com.atlassian.jira.plu... ] James Perkins closed JBLOGGING-121. ----------------------------------- Resolution: Done This was fixed with PR https://github.com/jboss-logging/log4j-jboss-logmanager/pull/14 > Static initializer of class org.apache.log4j.helpers.Loader relies on obsolete java versioning scheme > ----------------------------------------------------------------------------------------------------- > > Key: JBLOGGING-121 > URL: https://issues.jboss.org/browse/JBLOGGING-121 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-log4j > Reporter: Richard Opalka > Assignee: James Perkins > > JDK9 will introduce new java versioning scheme, see JEP-223 > http://openjdk.java.net/jeps/223 > Please update static initializer of class org.apache.log4j.helpers.Loader accordingly > to ensure smooth JDK9 migration. ATM the initializer will not handle Java 9 properly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2406) Credential store alias with upper-case letters can't be added when Java assertions are enabled

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2406?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2406: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Brian Stansberry) > Credential store alias with upper-case letters can't be added when Java assertions are enabled > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-2406 > URL: https://issues.jboss.org/browse/WFCORE-2406 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: ehsavoie Hugonnet > Priority: Critical > > When Java assertions are enable then adding credential store entry (alias) with upper case letters fails with assertion error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1337) Provide capabilities for paths

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1337?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1337: ------------------------------------- Issue Type: Bug (was: Enhancement) > Provide capabilities for paths > ------------------------------ > > Key: WFCORE-1337 > URL: https://issues.jboss.org/browse/WFCORE-1337 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > We need to be able to do reference validation for capabilities to avoid problems like WFCORE-1333. > This is going to take careful thought though. The PathManager is a bit of a complex beast. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8387) EJB remote invocations always execute in IO worker even when not supposed to

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8387?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-9610 to WFLY-8387: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8387 (was: JBEAP-9610) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: (was: 7.1.0.DR13) Affects Testing: (was: Regression) > EJB remote invocations always execute in IO worker even when not supposed to > ---------------------------------------------------------------------------- > > Key: WFLY-8387 > URL: https://issues.jboss.org/browse/WFLY-8387 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > > When you configure EJB3 subsystem so that remote invocations should be executed in thread pools of EJB3 subsystem instead of IO worker threads: > {noformat} > /subsystem=ejb3/service=remote:write-attribute(name=execute-in-worker,value=false) > {noformat} > This seems to have no effect and invocations are still executed in IO worker threads. > This is a regression, in EAP 7.0 it works correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2543) Upgrade JBoss Logging from 3.3.0.Final to 3.3.1.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2543?page=com.atlassian.jira.plugi... ] James Perkins moved JBEAP-9609 to WFCORE-2543: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2543 (was: JBEAP-9609) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) > Upgrade JBoss Logging from 3.3.0.Final to 3.3.1.Final > ----------------------------------------------------- > > Key: WFCORE-2543 > URL: https://issues.jboss.org/browse/WFCORE-2543 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2540) Update JACC Version property name and version to match WildFly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2540?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2540: ------------------------------------------ [~dlofthouse] We already hacked this with vault support, which is declared in the core schemas but won't actually work in core due to the missing picketbox. It's not great but I don't think it's the end of the world either. Better documentation than we have would be good though. I have my doubts whether hiding the API is actually an improvement. If I want to do something and the API is just missing, I think "Huh? Where did it go?" Whereas if I try and it fails with a useful error message, I can take meaningful action. > Update JACC Version property name and version to match WildFly > -------------------------------------------------------------- > > Key: WFCORE-2540 > URL: https://issues.jboss.org/browse/WFCORE-2540 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > > (The definition in WildFly can likely be removed as well) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2497: ------------------------------------------ [~dlofthouse] The way the WFCORE-1106 stuff works, if the child provides it's own capability, a parent resource being reload-required would only prevent Stage.RUNTIME execution by the child resource if the child's capability depends on the parent's. So no, there is no implicit dependency. For Core 4 we could consider auto-adding such a dependency as a programming convenience, perhaps following rules similar to what WFCORE-1106 did for finding letting children without capabilities find ones registered by the parent. I'll think a bit about how hard that would be to do sooner, but I'm concerned about cramming stuff in late in the cycle. > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta10 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2536) JmxSensitiveTestCase fails with security manager in WF core

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2536?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet reassigned WFCORE-2536: ----------------------------------------- Assignee: ehsavoie Hugonnet > JmxSensitiveTestCase fails with security manager in WF core > ----------------------------------------------------------- > > Key: WFCORE-2536 > URL: https://issues.jboss.org/browse/WFCORE-2536 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jan Tymel > Assignee: ehsavoie Hugonnet > > *org.jboss.as.test.integration.mgmt.access.JmxSensitiveTestCase* > {{cd testsuite/rbac/}} > {{mvn test -Dtest=JmxSensitiveTestCase -Dsecurity.manager -DtestLogToFile=false}} > {code} > 13:42:13,573 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service test.deployment.jmx: org.jboss.msc.service.StartException in service test.deployment.jmx: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.jar" from Service Module Loader") > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:111) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:785) > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanPermission" "org.wildfly.test.jmx.Dynamic#-[jboss.test:service=testdeployments]" "registerMBean")" in code source "(vfs:/content/test-jmx-deployment.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.test-jmx-deployment.jar" from Service Module Loader") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1842) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:333) > at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:534) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1536) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:878) > at org.wildfly.test.jmx.ServiceActivatorDeployment.registerMBean(ServiceActivatorDeployment.java:139) > at org.wildfly.test.jmx.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:99) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 March 2017