[JBoss JIRA] (WFLY-10864) MP Health reports UP when there is port collision for port 8080
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-10864?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-10864:
-----------------------------------------
WFLY-12342 is the intended solution for the scenario discussed in WFLY-10864.
> MP Health reports UP when there is port collision for port 8080
> ---------------------------------------------------------------
>
> Key: WFLY-10864
> URL: https://issues.redhat.com/browse/WFLY-10864
> Project: WildFly
> Issue Type: Enhancement
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> MP Health reports UP when there is port collision for port 8080.
> I have simple python app to acquire port 8080 and once it runs I start WF server
> {code}
> import SimpleHTTPServer
> import SocketServer
> PORT = 8080
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
> httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler)
> print "serving at port", PORT
> httpd.serve_forever()
> {code}
> WF reports Address already in use /127.0.0.1:8080, deployments are not deployed.
> Accessing http://localhost:9990/health/ reports "outcome":"UP"
> I think this is wrong and DOWN should be reported.
> Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly.
> I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-10864) MP Health reports UP when there is port collision for port 8080
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-10864?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFLY-10864.
-------------------------------------
Fix Version/s: 21.0.0.Beta1
Resolution: Duplicate Issue
> MP Health reports UP when there is port collision for port 8080
> ---------------------------------------------------------------
>
> Key: WFLY-10864
> URL: https://issues.redhat.com/browse/WFLY-10864
> Project: WildFly
> Issue Type: Enhancement
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 21.0.0.Beta1
>
>
> MP Health reports UP when there is port collision for port 8080.
> I have simple python app to acquire port 8080 and once it runs I start WF server
> {code}
> import SimpleHTTPServer
> import SocketServer
> PORT = 8080
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
> httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler)
> print "serving at port", PORT
> httpd.serve_forever()
> {code}
> WF reports Address already in use /127.0.0.1:8080, deployments are not deployed.
> Accessing http://localhost:9990/health/ reports "outcome":"UP"
> I think this is wrong and DOWN should be reported.
> Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly.
> I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-10864) MP Health reports UP when there is port collision for port 8080
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-10864?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-10864:
---------------------------------------
Assignee: Jeff Mesnil (was: Lin Gao)
> MP Health reports UP when there is port collision for port 8080
> ---------------------------------------------------------------
>
> Key: WFLY-10864
> URL: https://issues.redhat.com/browse/WFLY-10864
> Project: WildFly
> Issue Type: Enhancement
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> MP Health reports UP when there is port collision for port 8080.
> I have simple python app to acquire port 8080 and once it runs I start WF server
> {code}
> import SimpleHTTPServer
> import SocketServer
> PORT = 8080
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
> httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler)
> print "serving at port", PORT
> httpd.serve_forever()
> {code}
> WF reports Address already in use /127.0.0.1:8080, deployments are not deployed.
> Accessing http://localhost:9990/health/ reports "outcome":"UP"
> I think this is wrong and DOWN should be reported.
> Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly.
> I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-5650:
-------------------------------------
Can you please provide a reproducer for this? Or at least the source code (drl + java pojo) to reproduce the problem? Thanks.
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5650:
--------------------------------
Sprint: 2020 Week 37-39 (from Sep 7)
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-2016?page=com.atlassian.jira.plug... ]
Farah Juma resolved WFCORE-2016.
--------------------------------
Resolution: Out of Date
Resolving this one as "Out of Date" since this can no longer be reproduced.
> Change sasl-authentication-factor for management auth works after reload, but not after server restart
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2016
> URL: https://issues.redhat.com/browse/WFCORE-2016
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Reporter: Zach Rhoads
> Priority: Major
>
> I can successfully configure a new sasl-authentication-factory and assign it to the management interface:
> {code}
> /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir)
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add()
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"})
> /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"])
> /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles)
> /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper)
> /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}])
> /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth)
> reload
> {code}
> after reload, i am forced to re-authenticate and it succeeds:
> {code}
> [standalone@localhost:9990 /] reload
> Authenticating against security realm: exampleSaslRealm
> Username: user1
> Password:
> [standalone@localhost:9990 /]
> {code}
> Once i restart the server though and try to connect, i get a timeout:
> {code}
> $ ./jboss-cli.sh -c
> Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out
> {code}
> It also fails if i force no local auth:
> {code}
> $ ./jboss-cli.sh -c --no-local-auth
> Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out
> {code}/
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFCORE-2453) Complicated failure-descriptions in Elytron simple-permission-mapper
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-2453?page=com.atlassian.jira.plug... ]
Farah Juma resolved WFCORE-2453.
--------------------------------
Resolution: Out of Date
Resolving this one as "Out of Date" since the corresponding JBEAP issues was resolved as out of date.
> Complicated failure-descriptions in Elytron simple-permission-mapper
> --------------------------------------------------------------------
>
> Key: WFCORE-2453
> URL: https://issues.redhat.com/browse/WFCORE-2453
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta7
> Reporter: Ondrej Lukas
> Priority: Major
> Labels: user_experience
>
> There are complicated failure-descriptions in Elytron simple-permission-mapper. They include some details from exceptions which are not needed and can be confused for non-java administrators. Please handle these exceptions and provide some user friendly failure-description.
> Examples of complicated failure-description in simple-permission-mapper:
> * Wrong name of permission class:
> {code}
> /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.WrongLoginPermission,target-name=someName}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [org.wildfly.security.auth.permission.WrongLoginPermission].
> Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"org.wildfly.security.auth.permission.WrongLoginPermission\"
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.permission.WrongLoginPermission from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> * Adding permission, but non existing module is used:
> {code}
> /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.LoginPermission,target-name=someName,module=some.nonexist.module}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main
> Caused by: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> Suggestion for improvement:
> * use only description of failure, e.g. something like "module a.b.c. does not exist"
> * do not use any unneeded information - e.g. "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFCORE-2491) Complicated failure-description in Elytron constant-permission-mapper
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-2491?page=com.atlassian.jira.plug... ]
Farah Juma resolved WFCORE-2491.
--------------------------------
Resolution: Rejected
Resolving this one as "Rejected" since the corresponding JBEAP was rejected.
> Complicated failure-description in Elytron constant-permission-mapper
> ---------------------------------------------------------------------
>
> Key: WFCORE-2491
> URL: https://issues.redhat.com/browse/WFCORE-2491
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta7
> Reporter: Ondrej Lukas
> Priority: Major
> Labels: user_experience
>
> There is complicated failure-description in Elytron constant-permission-mapper. Failure description in CLI should not contain Exception or snippet of stacktrace. Please instead of "Caused by:" parts from example below use some non-java administrator friendly message.
> Complicated failure-description:
> {code}
> /subsystem=elytron/constant-permission-mapper=permission-mapper:add(permissions=[{class-name=WrongClass}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.permission-mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.permission-mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [WrongClass].
> Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"WrongClass\"
> Caused by: java.lang.ClassNotFoundException: WrongClass from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/temp/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.permission-mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFCORE-5136) NPE in ModelControllerMBeanHelper
by Bartosz Spyrko-Smietanko (Jira)
[ https://issues.redhat.com/browse/WFCORE-5136?page=com.atlassian.jira.plug... ]
Bartosz Spyrko-Smietanko reassigned WFCORE-5136:
------------------------------------------------
Assignee: Bartosz Spyrko-Smietanko (was: Kabir Khan)
> NPE in ModelControllerMBeanHelper
> ---------------------------------
>
> Key: WFCORE-5136
> URL: https://issues.redhat.com/browse/WFCORE-5136
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Reporter: Bartosz Spyrko-Smietanko
> Assignee: Bartosz Spyrko-Smietanko
> Priority: Blocker
> Labels: downstream_dependency, regression
>
> The fix for JBEAP-19870 causes a NPE being thrown for some JMX calls.
> {code}
> 15:50:42,596 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] (pool-13-thread-1) Unexpected internal error: java.lang.NullPointerException
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:556) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:487) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:193) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:727) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.AuthorizingMBeanServer.invoke(AuthorizingMBeanServer.java:258) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:71) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:66) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:313) [wildfly-elytron-auth-server-1.10.8.Final-redhat-00001.jar:1.10.8.Final-redhat-00001]
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:270) [wildfly-elytron-auth-server-1.10.8.Final-redhat-00001.jar:1.10.8.Final-redhat-00001]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254) [wildfly-controller-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225) [wildfly-controller-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:66) [wildfly-jmx-10.1.12.Final-redhat-00001.jar:10.1.12.Final-redhat-00001]
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_265]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_265]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_265]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months