[JBoss JIRA] (WFLY-3131) isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect index in java.lang.String.substring method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------
Jay SenSharma <jsenshar(a)redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from NEW to MODIFIED
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3131
> URL: https://issues.jboss.org/browse/WFLY-3131
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect index in java.lang.String.substring method. Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
> "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "logging"),
> ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3146:
-----------------------------------
https://github.com/wildfly/wildfly/pull/6067 updates Undertow
https://github.com/wildfly/wildfly/pull/6068 updates XNIO
With these two PRs in I expect this issue will be resolved.
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
> Key: WFLY-3146
> URL: https://issues.jboss.org/browse/WFLY-3146
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
> Reporter: Darren Jones
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: MemoryLeak
> Fix For: 8.0.1.Final
>
> Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl.
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated LOGMGR-95:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1079106
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
> Key: LOGMGR-95
> URL: https://issues.jboss.org/browse/LOGMGR-95
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Livingston
> Assignee: James Perkins
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
> Logger.getLogger("a");
> Logger.getLogger("a.b.c");
> Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3146:
-----------------------------------
It looks certain that upstream Undertow plus the aforementioned XNIO commits together fix this issue on Linux at least. [~ctomc] can you confirm Windows?
If Windows is OK, then we can resolve this issue once both XNIO and Undertow releases are tagged and are upstream.
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
> Key: WFLY-3146
> URL: https://issues.jboss.org/browse/WFLY-3146
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
> Reporter: Darren Jones
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: MemoryLeak
> Fix For: 8.0.1.Final
>
> Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl.
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3146:
-----------------------------------
Cautiously optimistic that we have a fix for the SSL issue, will confirm soon.
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
> Key: WFLY-3146
> URL: https://issues.jboss.org/browse/WFLY-3146
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
> Reporter: Darren Jones
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: MemoryLeak
> Fix For: 8.0.1.Final
>
> Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl.
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2493:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from MODIFIED to ON_QA
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
> Key: WFLY-2493
> URL: https://issues.jboss.org/browse/WFLY-2493
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Environment: JBoss AS 7.2.0.Final
> Reporter: Jonáš Trantina
> Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months