[JBoss JIRA] (WFCORE-3579) ERROR log occurs during CLI reload operation on server
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3579?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3579:
--------------------------------
Fix Version/s: 4.0.0.CR2
(was: 4.0.0.CR1)
> ERROR log occurs during CLI reload operation on server
> ------------------------------------------------------
>
> Key: WFCORE-3579
> URL: https://issues.jboss.org/browse/WFCORE-3579
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 4.0.0.Alpha9
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 4.0.0.CR2
>
> Attachments: cli.script.txt
>
>
> *Description of the issue:*
> ERROR log occurs during CLI reload operation on server:
> {{ERROR \[org.jboss.as.controller.management-operation\] (pool-3-thread-2) WFLYCTL0013: Operation ("read-attribute") failed - address: (\[("host" => "master")\]) - failure description: "WFLYCTL0201: Unknown attribute 'host-state'"}}
> This issue is regression against WF11
> Reload handler and its "host-state" code is [here|https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/jav...], but this issue is probably caused by some "debug -> error" logging change ...
> I'm able to reproduce this only on embedded server. Non-embedded server is probably too slow to hit this issue
> *How reproducible:*
> I see this intermittently on fast virtual machines
> *Steps to Reproduce:*
> # ./jboss-cli.sh --file=cli.script.txt
> *Content of cli.script.txt file*
> This file is attached to this jira, beginning of this file:
> {noformat}
> embed-host-controller --std-out=echo
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> reload --host=master --admin-only=true
> {noformat}
> *Actual results:*
> Standard output:
> {noformat}
> ...
> [0m[0m01:36:06,021 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Alpha9) starting
> [0m[31m01:36:06,061 ERROR [org.jboss.as.controller.management-operation] (CLI command executor) WFLYCTL0013: Operation ("read-attribute") failed - address: ([("host" => "master")]) - failure description: "WFLYCTL0201: Unknown attribute 'host-state'"
> [0m[0m01:36:06,072 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=native-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,073 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,097 INFO [org.jboss.as.patching] (MSC service thread 1-3) WFLYPAT0050: WildFly Full cumulative patch ID is: base, one-off patches include: none
> [0m[33m01:36:06,102 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /home/hudson/hudson_workspace/workspace/early-testing-cli-embedded-manual/4b767fc2/wildfly/domain/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> [0m[0m01:36:06,185 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=default/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,196 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=ha/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,204 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=full/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,217 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/profile=full-ha/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [0m[0m01:36:06,287 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Alpha9) (Host Controller) started in 266ms - Started 54 of 59 services (18 services are lazy, passive or on-demand)
> ...
> {noformat}
> *Expected results:*
> No errors in logs
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-2235:
--------------------------------
Fix Version/s: 4.0.0.CR2
(was: 4.0.0.CR1)
> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
> Key: WFCORE-2235
> URL: https://issues.jboss.org/browse/WFCORE-2235
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules, Server
> Affects Versions: 4.0.0.Alpha6
> Reporter: Brian Stansberry
> Assignee: Richard Opalka
> Fix For: 4.0.0.CR2
>
> Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore...
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> 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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
> at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
> at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
> at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
> ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3656) Replace commons-logging implementation with one that can delegate to jboss-logging
by James Perkins (JIRA)
James Perkins created WFCORE-3656:
-------------------------------------
Summary: Replace commons-logging implementation with one that can delegate to jboss-logging
Key: WFCORE-3656
URL: https://issues.jboss.org/browse/WFCORE-3656
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Fix For: 5.0.0.Alpha1
The current Apache Commons Logging implementation delegates to the JBoss Log Manager. This can be a problem for embedded servers where the JBoss Log Manager may not be used. We should have an implementation that writes to JBoss Logging. This will allow any log manager that JBoss Logging supports to be used.
This is currently blocking provisioning from working with the embedded server API.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBEE-189) Missing license CDDL 1.1 in license file, wrong content of licenses tag in pom.xml
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JBEE-189?page=com.atlassian.jira.plugin.s... ]
Scott Marlow updated JBEE-189:
------------------------------
Description:
Update the License file and pom.xml for license correctness.
jboss-j2eemgmt-api_1.1_spec, jboss-rmi-api_1.0_spec do not have a LICENSE file.
Update:
jboss-jaxb-api_2.2_spec
jboss-saaj-api_1.3_spec
jboss-jsp-api_2.3_spec
jboss-servlet-api_3.1_spec
jboss-servlet-api_4.0_spec
jboss-jaspi-api_1.1_spec
jboss-connector-api_spec
jboss-rmi-api_1.0_spec
jboss-j2eemgmt-api_1.1_spec
jboss-jsf-api_2.2_spec
jboss-el-api_3.0_spec
jboss-ejb-api_3.2_spec
jboss-concurrency-api_1.0_spec
was:
Update the License file and pom.xml for license correctness.
Update:
jboss-jaxb-api_2.2_spec
jboss-saaj-api_1.3_spec
jboss-jsp-api_2.3_spec
jboss-servlet-api_3.1_spec
jboss-servlet-api_4.0_spec
jboss-jaspi-api_1.1_spec
jboss-connector-api_spec
jboss-rmi-api_1.0_spec
jboss-j2eemgmt-api_1.1_spec
jboss-jsf-api_2.2_spec
jboss-el-api_3.0_spec
jboss-ejb-api_3.2_spec
jboss-concurrency-api_1.0_spec
> Missing license CDDL 1.1 in license file, wrong content of licenses tag in pom.xml
> ----------------------------------------------------------------------------------
>
> Key: JBEE-189
> URL: https://issues.jboss.org/browse/JBEE-189
> Project: JBoss JavaEE Spec APIs
> Issue Type: Task
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> Update the License file and pom.xml for license correctness.
> jboss-j2eemgmt-api_1.1_spec, jboss-rmi-api_1.0_spec do not have a LICENSE file.
> Update:
> jboss-jaxb-api_2.2_spec
> jboss-saaj-api_1.3_spec
> jboss-jsp-api_2.3_spec
> jboss-servlet-api_3.1_spec
> jboss-servlet-api_4.0_spec
> jboss-jaspi-api_1.1_spec
> jboss-connector-api_spec
> jboss-rmi-api_1.0_spec
> jboss-j2eemgmt-api_1.1_spec
> jboss-jsf-api_2.2_spec
> jboss-el-api_3.0_spec
> jboss-ejb-api_3.2_spec
> jboss-concurrency-api_1.0_spec
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when adding large deployment with audit logging enabled
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-695:
---------------------------------------------
[~brian.stansberry], yes stream is used both in batch and non batch.
> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
> Key: WFCORE-695
> URL: https://issues.jboss.org/browse/WFCORE-695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.CR4
> Reporter: James Livingston
> Assignee: Jean-Francois Denise
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
> at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
> at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when adding large deployment with audit logging enabled
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-695:
-----------------------------------------
[~jfdenise] Can this be resolved then?
> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
> Key: WFCORE-695
> URL: https://issues.jboss.org/browse/WFCORE-695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.CR4
> Reporter: James Livingston
> Assignee: Jean-Francois Denise
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
> at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
> at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi... ]
Ken Wills reassigned WFCORE-3655:
---------------------------------
Assignee: Ken Wills
> Improve embedded HC started with empty config state reporting?
> --------------------------------------------------------------
>
> Key: WFCORE-3655
> URL: https://issues.jboss.org/browse/WFCORE-3655
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Minor
>
> This is a discussion ticket, and I'm really only making it to track the discussion at the moment.
> Alexey and I had a discussion regarding this, and I thought it would be useful to open this and get other feedback.
> Currently, when an embedded host controller is started with an empty config, a partial domain controller start is performed and then paused until the /host=foo:add command is issued.
> In the case that the HC is being started programatically it seems desirable to be able to check this step has been completed.
> Using the command from the CLI / inside a cli script doesn't have this problem as the CLI waits for the response before continuuing.
> Some clients poll on the /host=foo:host-status attribute, this isn't present until a host has been actually added though.
> the existing options are:
> (a) Like the CLI, just wait until the operation completes. I think this should currently always work.
> (b) Poll on the existence of the /host resource. If this is registered, then you can safely try to add your host (after all there may already be one.)
> Since the host hasn't been added, it doesn't make a lot of sense to provided a default status, as theres no /host=foo to hold the attribute.
> Other thoughts? Personally I'm a fan of (a). And I think that should always be sufficient. I'm not really sure what the programmatic expectations are for using ops like this are in general. Is behavior always assumed to be synchronous, so the end client doesn't need to poll or wait etc?
> [~aloubyansky] Feel free to comment and correct me if I was inaccurate about something.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9914) Server reload breaks security context
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-9914:
-------------------------------------
Summary: Server reload breaks security context
Key: WFLY-9914
URL: https://issues.jboss.org/browse/WFLY-9914
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 11.0.0.Final
Environment: Ubuntu 16.04 LTS, Oracle JDK 1.8.0_161
Reporter: Harald Wellmann
Assignee: Darran Lofthouse
h3. Summary
A minimal example webapp using Soteria and DeltaSpike Security works as expected when first deployed to WildFly.
After issuing a {{reload}} command via {{jboss-cli.sh}}, the application no longer works, since no groups are associated to the caller principal.
The problem no longer occurs after a server shutdown and restart.
h3. Details
{noformat}
# Start server
$ ${JBOSS_HOME}/bin/standalone.sh
# Build and deploy demo
$ git clone https://github.com/hwellmann/security-demo.git
$ cd security-demo
$ mvn deploy
# Request protected resource
$ curl -u operator:secret http://localhost:8080/api/version
{"version":1}
# Reload server
$ ${JBOSS_HOME}/bin/jboss-cli.sh -c --command=:reload
# Issue same request, access denied
$ curl -u operator:secret http://localhost:8080/api/version
{"message":"requested access to the resource is denied"}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months