[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3144:
------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Paul Ferraro
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
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
12 years, 3 months
[JBoss JIRA] (JBLOGGING-101) Each custom log handler defined in standalone adds a root log4j console appender
by John L (JIRA)
John L created JBLOGGING-101:
--------------------------------
Summary: Each custom log handler defined in standalone adds a root log4j console appender
Key: JBLOGGING-101
URL: https://issues.jboss.org/browse/JBLOGGING-101
Project: JBoss Logging
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jboss-logging-log4j
Reporter: John L
Assignee: James Perkins
JBoss 7.1.3 Logging custom handlers which are used to wrap existing log4j handlers
into jboss logging handlers calls
org.jboss.as.logging.handlers.custom.PropertiesConfigurator
which calls org.apache.log4j.BasicConfigurator.configure()
which by default adds a ConsoleAppender. Maybe should be calling
org.apache.log4j.BasicConfigurator.configure(new NullAppender()); to initialize log4j.
Net result is all log4j messages get forwarded to jboss logging add also get sent to the default ConsoleAppender which then writes it out stdout which then jboss catches
as stdout. So we have 3 custom handlers in our jboss configuration so we get 4 messages
to the screen. (1 for real category and 3 for each console appender added).
Not sure if this is reported in correct project.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2950) jboss-cli using https-remoting: command not executed if certificate is unrecognised
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2950?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2950:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1026418|https://bugzilla.redhat.com/show_bug.cgi?id=1026418] from MODIFIED to ON_QA
> jboss-cli using https-remoting: command not executed if certificate is unrecognised
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2950
> URL: https://issues.jboss.org/browse/WFLY-2950
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI, Domain Management
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 Pro
> Reporter: Darren Jones
> Assignee: Darran Lofthouse
> Labels: cli, shutdown
> Fix For: 8.0.1.Final
>
>
> When using the https management interface from jboss-cli, commands passed with a command line option (such as --command=:shutdown) are not executed if the server certificate is unrecognised - even if accepting the certificate [T]emporarily or [P]ermenantly.
> It appears to be due to the CommandContextImpl.handleSSLFailure() method, which calls error("Unable to connect..."). The error() method sets the exitCode to 1. So, when CliLauncher.processCommands() subsequently runs, it sees that the cmdCtx.exitCode is 1 and ignores any commands.
> I guess the handleSSLFailure needs to reset the exitCode to 0 if the user chooses [T] or [P].
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2214) Allow additional environment properties to be set for outbound LDAP connections used by security realms.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2214:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1015303|https://bugzilla.redhat.com/show_bug.cgi?id=1015303] from MODIFIED to ON_QA
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2214
> URL: https://issues.jboss.org/browse/WFLY-2214
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes. If the ldap server is down, it could take 2 minutes for the connection to timeout. This can cause unneeded delay if you have configured multiple ldap servers for failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
> result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
> String url = config.require(URL).asString();
> result.put(Context.PROVIDER_URL,url);
> + result.put("com.sun.jndi.ldap.connect.timeout", "500");
> return result;
> }
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2474) Security subsystem does not handle acl's module properly, and is missing transformer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from MODIFIED to ON_QA
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2474
> URL: https://issues.jboss.org/browse/WFLY-2474
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> <acl>
> <acl-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </acl-module>
> </acl>
> {code}
> becomes
> {code}
> <acl>
> <login-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </login-module>
> </acl>
> {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
12 years, 3 months
[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:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from MODIFIED to ON_QA
> 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
12 years, 3 months