October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets

by Dennis Reed (JIRA)

Dennis Reed created WFCORE-1029: ----------------------------------- Summary: ManagedSocketFactory doesn't work for client sockets Key: WFCORE-1029 URL: https://issues.jboss.org/browse/WFCORE-1029 Project: WildFly Core Issue Type: Bug Affects Versions: 2.0.0.CR5 Reporter: Dennis Reed SocketBindingManagerImpl does not work with client sockets. It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address. This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly

by Dennis Reed (JIRA)

Dennis Reed created WFLY-5449: --------------------------------- Summary: Custom socket factory for JGroups subsystem not set correctly Key: WFLY-5449 URL: https://issues.jboss.org/browse/WFLY-5449 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR2 Reporter: Dennis Reed Assignee: Paul Ferraro Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport. This is not the correct API to use, and it gets overwritten when the JGroups channel starts. A custom socket factory should be set on the JChannel. The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1026) Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1026?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1026: ---------------------------------- Summary: Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final (was: Upgrade jboss-logmanager from 2.0.0.Final to 2.0.1.Final) > Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final > -------------------------------------------------------- > > Key: WFCORE-1026 > URL: https://issues.jboss.org/browse/WFCORE-1026 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. The 2.0.1.Final release only contains that fix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1026) Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1026?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1026: ---------------------------------- Description: Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. (was: Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. The 2.0.1.Final release only contains that fix.) > Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final > -------------------------------------------------------- > > Key: WFCORE-1026 > URL: https://issues.jboss.org/browse/WFCORE-1026 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-808) Password not passed into DatabaseServerLoginModule

by Lorenz Froihofer (JIRA)

[ https://issues.jboss.org/browse/SECURITY-808?page=com.atlassian.jira.plug... ] Lorenz Froihofer commented on SECURITY-808: ------------------------------------------- Tracked down the issue a little bit further (picketbox-4.9.2.Final in Wildfly 9.0.1.Final): JBossCallbackHandler.getPassword() falls back to try the dynamic invocation of a method named "toCharArray": {code:java} Method m = credential.getClass().getMethod("toCharArray", types); Object[] args = {}; password = (char[]) m.invoke(credential, args); {code} This fails with a NoSuchMethodException for a RemotingConnectionCredential object as this class does not offer such a method. The exception handling just tries to create a credential by using the "toString" method on the credential object (the RemotingConnectionCredential) - leading to a String such as org.jboss.as.security.remoting.RemotingConnectionCredential@22341334 instead of the real password. As far as the code looks like, the RemotingConnectionCredential should allow for a callback to get the password, but looking at it or the wrapped Connection class, one can only get the username through org.jboss.remoting3.Connection.getUserInfo(), but no password. This seems to be a more general issue not only related to the DatabaseServerLoginModule but to custom login modules as well: https://developer.jboss.org/message/866429 > Password not passed into DatabaseServerLoginModule > -------------------------------------------------- > > Key: SECURITY-808 > URL: https://issues.jboss.org/browse/SECURITY-808 > Project: PicketBox > Issue Type: Bug > Environment: WildFly8 on Windows 7 64-bit > Reporter: Stefan Eder > Assignee: Stefan Guilhen > Priority: Critical > > Trying to migrate an application to WildFly (from AS6.1) the migration went pretty smooth except for using the security domain. > The application uses a the ClientLoginModule on the client side and the DatabaseserverLoginModule on the server side. > > Though the DatabaseServerLoginModule is called the validation of the password fails. I debugged it and the reason seems to be that in {{org.jboss.security.auth.callback.JBossCallbackHandler.getPassword()}} a {{org.jboss.as.security.remoting.RemotingConnectionCredential@22341334}} is not handled and hence instead of a password the String {{org.jboss.as.security.remoting.RemotingConnectionCredential@22341334}} is passed through to the DatabaseLoginModule. > See also [DatabaseServerLoginModule broken?|https://community.jboss.org/message/863295] and the related posts -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-935) tomcat7 unable to deploy Execution server

by Siarhei Yarkavy (JIRA)

[ https://issues.jboss.org/browse/DROOLS-935?page=com.atlassian.jira.plugin... ] Siarhei Yarkavy updated DROOLS-935: ----------------------------------- Environment: Windows 7 64bit sp1 java 7u60 64bit tomcat 7.0.54 > tomcat7 unable to deploy Execution server > ----------------------------------------- > > Key: DROOLS-935 > URL: https://issues.jboss.org/browse/DROOLS-935 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.3.0.Final > Environment: Windows 7 64bit sp1 > java 7u60 64bit > tomcat 7.0.54 > Reporter: Siarhei Yarkavy > Assignee: Edson Tirelli > Attachments: catalina.2015-10-01.zip > > > Unable to properly deploy Execution server into tomcat7 container. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-935) tomcat7 unable to deploy Execution server

by Siarhei Yarkavy (JIRA)

Siarhei Yarkavy created DROOLS-935: -------------------------------------- Summary: tomcat7 unable to deploy Execution server Key: DROOLS-935 URL: https://issues.jboss.org/browse/DROOLS-935 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 6.3.0.Final Reporter: Siarhei Yarkavy Assignee: Edson Tirelli Attachments: catalina.2015-10-01.zip Unable to properly deploy Execution server into tomcat7 container. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1028) Poor handling of invalid roles

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1028: ---------------------------------------- Summary: Poor handling of invalid roles Key: WFCORE-1028 URL: https://issues.jboss.org/browse/WFCORE-1028 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.0.0.CR5 Reporter: Brian Stansberry A CLI request with an invalid value in the "roles" header results in improper behavior: {code} [domain@localhost:9990 /] /host=*:read-resource{roles=slave-monitor} { "outcome" => "failed", "result" => [], "rolled-back" => true } {code} The op should fail because the role doesn't exist, but there is no failure-description. The following is dumped in the HC log: {code} [Host Controller] 12:22:12,314 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve") failed - address: ([]): java.lang.IllegalArgumentException: WFLYCTL0327: Unknown role 'slave-monitor' [Host Controller] at org.jboss.as.controller.access.rbac.StandardRoleMapper.canRunAs(StandardRoleMapper.java:95) [Host Controller] at org.jboss.as.controller.access.rbac.RunAsRoleMapper.mapRoles(RunAsRoleMapper.java:143) [Host Controller] at org.jboss.as.controller.access.rbac.RunAsRoleMapper.mapRoles(RunAsRoleMapper.java:71) [Host Controller] at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:109) [Host Controller] at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:91) [Host Controller] at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:99) [Host Controller] at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1753) [Host Controller] at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1651) [Host Controller] at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:833) [Host Controller] at org.jboss.as.controller.OperationContextImpl.readResource(OperationContextImpl.java:818) [Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ModelAddressResolver.execute(GlobalOperationHandlers.java:402) [Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ModelAddressResolver.execute(GlobalOperationHandlers.java:306) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391) [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147) [Host Controller] at java.security.AccessController.doPrivileged(Native Method) [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:422) [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147) [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299) [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519) [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [Host Controller] at java.lang.Thread.run(Thread.java:745) [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1027) Inconsistent read-resource results with host scoped roles

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-1027: ---------------------------------- Summary: Inconsistent read-resource results with host scoped roles Key: WFCORE-1027 URL: https://issues.jboss.org/browse/WFCORE-1027 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.0.0.CR5 Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 2.0.0.CR6 Setting up host scoped roles as follows https://gist.github.com/heiko-braun/0dc810ed04db8739defd there are inconsistent results in the filtering. When using a role which only selects the master there is no access-control response header showing the filtered resources, and the slave wrongly appears in the results: {code} [domain@localhost:9990 /] /host=*:read-resource{roles=master-monitor} { "outcome" => "success", "result" => [ { "address" => [("host" => "master")], "outcome" => "success", "result" => { "directory-grouping" => "by-server", "domain-controller" => {"local" => {}}, "management-major-version" => 4, "management-micro-version" => 0, "management-minor-version" => 0, "master" => true, "name" => "master", "namespaces" => [], "organization" => undefined, "product-name" => "WildFly Core", "product-version" => "2.0.0.CR6-SNAPSHOT", "release-codename" => "Kenny", "release-version" => "2.0.0.CR6-SNAPSHOT", "schema-locations" => [], "core-service" => { "host-environment" => undefined, "platform-mbean" => undefined, "management" => undefined, "discovery-options" => undefined, "ignored-resources" => undefined, "patching" => undefined, "module-loading" => undefined }, "extension" => {"org.jboss.as.jmx" => undefined}, "interface" => { "management" => undefined, "public" => undefined, "unsecure" => undefined }, "jvm" => {"default" => undefined}, "path" => undefined, "server" => { "server-one" => undefined, "server-two" => undefined, "server-three" => undefined }, "server-config" => { "server-one" => undefined, "server-two" => undefined, "server-three" => undefined }, "socket-binding-group" => undefined, "subsystem" => {"jmx" => undefined}, "system-property" => undefined } }, { "address" => [("host" => "localhost")], "outcome" => "success", "result" => undefined } ] } {code} When using a role that only selects the slave we get a proper access-control header {code} [domain@localhost:9990 /] /host=*:read-resource{roles=slave-maintainer} { "outcome" => "success", "result" => [{ "address" => [("host" => "localhost")], "outcome" => "success", "result" => undefined }], "response-headers" => {"access-control" => [{ "absolute-address" => [], "relative-address" => [], "filtered-children-types" => ["host"] }]} {code} The same output on master with WFCORE-994 applied: {code} [domain@localhost:9990 /] /host=*:read-resource{roles=slave-maintainer} { "outcome" => "success", "result" => [{ "address" => [("host" => "slave")], "outcome" => "success", "result" => { "directory-grouping" => "by-server", "domain-controller" => {"remote" => { "protocol" => undefined, "port" => undefined, "host" => undefined, "username" => undefined, "ignore-unused-configuration" => undefined, "admin-only-policy" => undefined, "security-realm" => "ManagementRealm" }}, "management-major-version" => 4, "management-micro-version" => 0, "management-minor-version" => 0, "master" => false, "name" => "slave", "namespaces" => [], "organization" => undefined, "product-name" => undefined, "product-version" => undefined, "release-codename" => "Kenny", "release-version" => "2.0.0.CR6-SNAPSHOT", "schema-locations" => [], "core-service" => { "host-environment" => undefined, "platform-mbean" => undefined, "management" => undefined, "discovery-options" => undefined, "ignored-resources" => undefined, "patching" => undefined, "module-loading" => undefined }, "extension" => {"org.jboss.as.jmx" => undefined}, "interface" => { "management" => undefined, "public" => undefined, "unsecure" => undefined }, "jvm" => {"default" => undefined}, "path" => undefined, "server" => { "server-one" => undefined, "server-two" => undefined }, "server-config" => { "server-one" => undefined, "server-two" => undefined }, "socket-binding-group" => undefined, "subsystem" => {"jmx" => undefined}, "system-property" => undefined } }], "response-headers" => {"access-control" => [{ "absolute-address" => [], "relative-address" => [], "filtered-children-types" => ["host"] }]} } {code} master-monitor should behave the same as slave-maintainer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once

by James Perkins (JIRA)

James Perkins created LOGMGR-123: ------------------------------------ Summary: TCP reconnect will only attempt to reconnect once Key: LOGMGR-123 URL: https://issues.jboss.org/browse/LOGMGR-123 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins Assignee: James Perkins The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2015