[JBoss JIRA] (WFLY-5557) Kerberos authentication for remoting on hostname which contains uppercase letter
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-5557?page=com.atlassian.jira.plugin.... ]
Lin Gao reassigned WFLY-5557:
-----------------------------
Assignee: Lin Gao
> Kerberos authentication for remoting on hostname which contains uppercase letter
> --------------------------------------------------------------------------------
>
> Key: WFLY-5557
> URL: https://issues.jboss.org/browse/WFLY-5557
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Remoting, Security
> Affects Versions: 10.0.0.CR3
> Reporter: Martin Choma
> Assignee: Lin Gao
> Priority: Critical
>
> When EAP runs on server, which contains upper case in hostname (e.g. localhost.Localdomain), it is unpossible to make kerberos authentication in remoting to work properly.
> JDK constructs TGT-REQ with lower case hostname. But remoting client create connection to EAP with upper case letters, what cause problems.
> RFC4120 "The Kerberos Network Authentication Service" [1] in chapter "6.2.1. Name of Server Principals" requires ??Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host MUST be lowercase.??
> Based on information from RFC, IMHO, EAP should handle such scenario. Either remoting client should send lowercase hostname or security realm should map principal case insensitively and look for lower-case keytab record, e.g. remote/localhost.localdomain.
> [1] https://www.ietf.org/rfc/rfc4120.txt
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5608) Unable to configure https using CLI with attribute enabled-cipher-suites
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5608?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-571 to WFLY-5608:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-5608 (was: UNDERTOW-571)
Component/s: Web (Undertow)
(was: Security)
Affects Version/s: (was: 1.3.1.Final)
> Unable to configure https using CLI with attribute enabled-cipher-suites
> ------------------------------------------------------------------------
>
> Key: WFLY-5608
> URL: https://issues.jboss.org/browse/WFLY-5608
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> User is unable to configure https using enabled-cipher-suites attribute
> {code}
> [standalone@localhost:9990 /] /core-service=management/security-realm=FIPSRealm:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-cipher-suites="DHE", enabled-protocols="TLSv1")
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.NullPointerException"}},
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> {code}
> 14:52:20,753 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.NullPointerException
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:120)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 14:52:20,753 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
> This works OK. It means reload is used between commands
> {code}
> /core-service=management/security-realm=FIPSRealm:add
> /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> reload
> /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-cipher-suites="DHE", enabled-protocols="TLSv1")
> {code}
> Also same commands without enabled-cipher-suites works OK
> {code}
> /core-service=management/security-realm=FIPSRealm:add
> /core-service=management/security-realm=FIPSRealm/server-identity=ssl:add(keystore-provider=PKCS11, keystore-password="NSS FIPS 140-2 Certificate DB")
> /subsystem=undertow/server=default-server/https-listener=https:add(socket-binding=https, security-realm=FIPSRealm, enabled-protocols="TLSv1")
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Stefano Picozzi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-932?page=com.atlassian.jira.plugin... ]
Stefano Picozzi updated DROOLS-932:
-----------------------------------
Attachment: Drools-932-TestCase.zip
The test case now works. Two changes were needed:
1) Added following line to all my rule files, otherwise get Exception splat:
dialect "mvel"
2) Added the Header as suggested above to the POST invocation.
To replicate pull down my docker image spicozzi/weightwatcher2 and then run the "post" sh script in attached file. Note that there is no need to create the kie-server Container, as I am leveraging new 6.3 feature which persists the container once created.
> kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-932
> URL: https://issues.jboss.org/browse/DROOLS-932
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
> Reporter: Stefano Picozzi
> Assignee: Maciej Swiderski
> Priority: Blocker
> Attachments: Drools-932-TestCase.zip, Drools-932-TestCase.zip
>
>
> The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
> However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:
> 07:24:27,998 INFO [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl@3c402d4b
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
> at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> ... 32 more
> Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 35 more
> Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 46 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1089) IgnoredResourcesProfileCloneTestCase does not well for domain stabilization following reload
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1089:
----------------------------------------
Summary: IgnoredResourcesProfileCloneTestCase does not well for domain stabilization following reload
Key: WFCORE-1089
URL: https://issues.jboss.org/browse/WFCORE-1089
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Test Suite
Affects Versions: 2.0.0.CR9
Reporter: Brian Stansberry
IgnoredResourcesProfileCloneTestCase several times reloads the slave HC without restarting its servers. But it then does not wait for those servers to reconnect before continuing on. This means the servers may not be reattached to the domain when further modifications are made.
I'm quite certain this is the cause of the failure at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=76866&tab=buil... and the other time that test failed.
IgnoredResourcesProfileCloneTestCase reloads the slave and then exits. CompositeOperationTestCase follows and immediately adds system-property=composite-op in its @Before method. The other-two server doesn't get this op as it's not reconnected. The test then later fails because the other-two server's state is not as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5607) EJB Server side is needlessly closing remoting channel
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-5607:
----------------------------------
Summary: EJB Server side is needlessly closing remoting channel
Key: WFLY-5607
URL: https://issues.jboss.org/browse/WFLY-5607
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.CR4
Reporter: Brad Maxwell
When an EJB Bean throws a Runtime exception, it is causing the server side to close the remoting channel. This causes several issues such as performance issue of having to recreate the channel, channel leak on the client side and some occasional EJBCLIENT...25 - no ejb receiver exceptions on the client side.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1088) NPE on a domain server when configuring a deployment logging configuration resource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1088?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1088:
---------------------------------------
The issue wasn't just domain servers. It was seen there because the console does a composite {{read-resource}} when a deployment is being replaced. The same behavior could be seen on a standalone server if multiple deployments are present and at least one deployment is using a custom logging configuration. Executing a composite operation to read the resources would result in an NPE.
> NPE on a domain server when configuring a deployment logging configuration resource
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-1088
> URL: https://issues.jboss.org/browse/WFCORE-1088
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
> {code}
> [Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
> [Server:server-one] ("subsystem" => "logging"),
> [Server:server-one] ("configuration" => "default"),
> [Server:server-one] ("logger" => "com.arjuna")
> [Server:server-one] ]): java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
> [Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1087) ManagementResourceRegistration.getOrderedChildTypes() does not account for override models
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1087?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1087:
-------------------------------------
Priority: Major (was: Blocker)
> ManagementResourceRegistration.getOrderedChildTypes() does not account for override models
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-1087
> URL: https://issues.jboss.org/browse/WFCORE-1087
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR9
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Final
>
>
> ManagementResourceRegistration.getOrderedChildTypes() is implemented by simply reading the local state of ConcreteResourceRegistration. It needs to work like getAttributeNames(), by delegating to the root node which in turn uses NodeSubregistry to combine data from any singleton override registration and the corresponding wildcard registration.
> Same kind of problem as WFCORE-1086.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month