June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8458: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1436390|https://bugzilla.redhat.com/show_bug.cgi?id=1436390] from MODIFIED to ON_QA > NPE when MBean does not have no-arg constructor > ----------------------------------------------- > > Key: WFLY-8458 > URL: https://issues.jboss.org/browse/WFLY-8458 > Project: WildFly > Issue Type: Bug > Components: JMX, Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 11.0.0.Beta1 > > > NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE > {code} > 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > 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:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129) > at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > Caused by: java.lang.NullPointerException > at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131) > ... 9 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1168) Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1168?page=com.atlassian.jira.plugin.s... ] Hynek Švábek commented on ELY-1168: ----------------------------------- [~soul2zimate] Keep on mind that problem is when you use "entry-type" without value. > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > ---------------------------------------------------------------------------------------------------------- > > Key: ELY-1168 > URL: https://issues.jboss.org/browse/ELY-1168 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Chao Wang > > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > It seems to be little confusing. I prefer error message rather than success. > Reason why it works now is because as a value is used default value for entry-type. > *How to reproduce* > {code} > java -jar ./bin/wildfly-elytron-tool.jar credential-store --add secret_alias --create -l store123.jceks --password pass123 -x test -n > Alias "secret_alias" has been successfully stored > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ] Ondrej Lukas commented on WFLY-8760: ------------------------------------ [~gaol] I am able reproduce it with Servlet which calls: {code} import org.jboss.security.mapping.MappingContext; import org.jboss.security.mapping.MappingManager; import org.jboss.security.mapping.MappingType; import org.picketbox.factories.SecurityFactory; ... MappingManager mm = SecurityFactory.getMappingManager(securityDomainName); MappingContext<Object> mc = mm.getMappingContext(MappingType.ATTRIBUTE.name()); ... {code} Then following AccessControlException is thrown: {code} ERROR [io.undertow.request] (default task-9) UT005023: Exception handling request to /844252ce-02ae-4a7a-b414-4be69116984f/protected/LdapAttributeMappingProviderServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createClassLoader")" in code source "(vfs:/content/844252ce-02ae-4a7a-b414-4be69116984f.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.844252ce-02ae-4a7a-b414-4be69116984f.war" 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 java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611) at org.wildfly.security.manager.WildFlySecurityManager.checkCreateClassLoader(WildFlySecurityManager.java:308) at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274) at java.lang.ClassLoader.<init>(ClassLoader.java:335) at java.security.SecureClassLoader.<init>(SecureClassLoader.java:99) at org.jboss.as.security.plugins.ModuleClassLoaderLocator$CombinedClassLoader.<init>(ModuleClassLoaderLocator.java:82) at org.jboss.as.security.plugins.ModuleClassLoaderLocator.get(ModuleClassLoaderLocator.java:72) at org.jboss.security.plugins.mapping.JBossMappingManager.generateMappingContext(JBossMappingManager.java:111) at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:74) ... {code} > get method of ModuleClassLoaderLocator requires createClassLoader permission > ---------------------------------------------------------------------------- > > Key: WFLY-8760 > URL: https://issues.jboss.org/browse/WFLY-8760 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Lin Gao > Priority: Critical > > There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission. > That means: > * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission) > ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator. > * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1168) Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-1168?page=com.atlassian.jira.plugin.s... ] Chao Wang commented on ELY-1168: -------------------------------- Hi [~pskopek], Is this a valid issue to you ? CredentialStoreCommand deliberately set option {{entry-type}} to have an optional argument at [CredentialStoreCommand.java|https://github.com/wildfly-security/wildfly-e...], if this is valid bug, fix would be removing this line. > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > ---------------------------------------------------------------------------------------------------------- > > Key: ELY-1168 > URL: https://issues.jboss.org/browse/ELY-1168 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Chao Wang > > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > It seems to be little confusing. I prefer error message rather than success. > Reason why it works now is because as a value is used default value for entry-type. > *How to reproduce* > {code} > java -jar ./bin/wildfly-elytron-tool.jar credential-store --add secret_alias --create -l store123.jceks --password pass123 -x test -n > Alias "secret_alias" has been successfully stored > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ] Lin Gao reassigned WFLY-8760: ----------------------------- Assignee: Lin Gao (was: Darran Lofthouse) > get method of ModuleClassLoaderLocator requires createClassLoader permission > ---------------------------------------------------------------------------- > > Key: WFLY-8760 > URL: https://issues.jboss.org/browse/WFLY-8760 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Lin Gao > Priority: Critical > > There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission. > That means: > * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission) > ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator. > * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1168) Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-1168?page=com.atlassian.jira.plugin.s... ] Chao Wang reassigned ELY-1168: ------------------------------ Assignee: Chao Wang (was: Darran Lofthouse) > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > ---------------------------------------------------------------------------------------------------------- > > Key: ELY-1168 > URL: https://issues.jboss.org/browse/ELY-1168 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Chao Wang > > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > It seems to be little confusing. I prefer error message rather than success. > Reason why it works now is because as a value is used default value for entry-type. > *How to reproduce* > {code} > java -jar ./bin/wildfly-elytron-tool.jar credential-store --add secret_alias --create -l store123.jceks --password pass123 -x test -n > Alias "secret_alias" has been successfully stored > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by John Ament (JIRA)

[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ] John Ament commented on WFLY-8488: ---------------------------------- [~rhusar] ping? :-) > Usage of JGroups JDBC_PING attempts to delete row too late > ---------------------------------------------------------- > > Key: WFLY-8488 > URL: https://issues.jboss.org/browse/WFLY-8488 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Paul Ferraro > > I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. > In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2895: ------------------------------------- Summary: Save memory in RuntimeCapability ServiceName creation (was: Save memory in dynamic RuntimeCapability ServiceName creation) > Save memory in RuntimeCapability ServiceName creation > ----------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates its ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in dynamic RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2895: ------------------------------------- Description: RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates its ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. was: RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. > Save memory in dynamic RuntimeCapability ServiceName creation > ------------------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates its ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in dynamic RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2895: ------------------------------------- Description: RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. was: RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. Also RuntimeCapability should not create a ServiceName even if the cap has no serviceValueType. > Save memory in dynamic RuntimeCapability ServiceName creation > ------------------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates it's ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017