June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6768) ServletResourceManager does not implement isResourceChangeListenerSupported correctly

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6768: ------------------------------------ Summary: ServletResourceManager does not implement isResourceChangeListenerSupported correctly Key: WFLY-6768 URL: https://issues.jboss.org/browse/WFLY-6768 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6742) javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6742?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6742: -------------------------------------- Can you provide a reproducer? How is the charset being set to UTF-8? > javax.servlet.http.Part.getSubmittedFileName() uses wrong encoding > ------------------------------------------------------------------ > > Key: WFLY-6742 > URL: https://issues.jboss.org/browse/WFLY-6742 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final, 10.0.0.Final > Environment: Ubuntu 16.04 LTS > oracle java > java version "1.8.0_91" > Java(TM) SE Runtime Environment (build 1.8.0_91-b14) > Wildfly 8.2.0.Final > Wildfly 10.0.0.Final > Reporter: Maxim Wirt > Assignee: Stuart Douglas > > Servlet 3.1 file upload feature implementation uses incorrect character set for decoding file names > request.getCharacterEncoding() returns "UTF-8", > System property file.encoding is set to UTF-8, but > javax.servlet.http.Part.getSubmittedFileName() returns file name encoded using Latin character set > all non-latin symbols in name of the file become unreadably characters. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6655) When creating JMS bridge management API should pass bridge name to JMS broker

by Chen Maoqian (JIRA)

[ https://issues.jboss.org/browse/WFLY-6655?page=com.atlassian.jira.plugin.... ] Chen Maoqian reassigned WFLY-6655: ---------------------------------- Assignee: Chen Maoqian (was: Jeff Mesnil) > When creating JMS bridge management API should pass bridge name to JMS broker > ----------------------------------------------------------------------------- > > Key: WFLY-6655 > URL: https://issues.jboss.org/browse/WFLY-6655 > Project: WildFly > Issue Type: Bug > Components: JMS > Environment: JBoss EAP 7.0 > Reporter: Tom Ross > Assignee: Chen Maoqian > > In situations where there are multiple JMS bridges being created it woudl help if bridge name is logged in the server name. This helps with recognising which JMS bridge is having problems. > For this to work the JBoss messaging API layer has to pass bridge name to the JMS broker. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1618) Management request handling cleanup

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1618: ---------------------------------------- Summary: Management request handling cleanup Key: WFCORE-1618 URL: https://issues.jboss.org/browse/WFCORE-1618 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Alpha3 Clean up some of the code used in management request handling to try and reduce the complexity. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6767) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/WFLY-6767?page=com.atlassian.jira.plugin.... ] Derek Horton moved JBEAP-5114 to WFLY-6767: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6767 (was: JBEAP-5114) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Target Release: (was: 7.backlog.GA) > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security > ---------------------------------------------------------------------------------------- > > Key: WFLY-6767 > URL: https://issues.jboss.org/browse/WFLY-6767 > Project: WildFly > Issue Type: Bug > Reporter: Derek Horton > > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following: > <security-realm name="ManagementRealm"> > <authentication> > <jaas name="jmx-console"/> > </authentication> > <authorization map-groups-to-roles="false"> > <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> > </authorization> > </security-realm> > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="RealmUsersRoles" flag="required"> > <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > </login-module> > </authentication> > </security-domain> > The following error is logged during the authentication attempt: > 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))] > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794) > at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) > at javax.security.auth.login.LoginContext.login(LoginContext.java:587) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347) > at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174) > at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161) > at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > 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) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6766) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-6766: ---------------------------------- Summary: Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress Key: WFLY-6766 URL: https://issues.jboss.org/browse/WFLY-6766 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Kabir Khan For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails. This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1606: ------------------------------------- Fix Version/s: 3.0.0.Beta1 > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Fix For: 3.0.0.Beta1 > > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2083) Specifying prefix in S3_PING or GOOGLE_PING causes property validation failures

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2083?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2083: --------------------------- Fix Version/s: 3.6.10 4.0 > Specifying prefix in S3_PING or GOOGLE_PING causes property validation failures > ------------------------------------------------------------------------------- > > Key: JGRP-2083 > URL: https://issues.jboss.org/browse/JGRP-2083 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.9 > Reporter: Alan Field > Assignee: Bela Ban > Fix For: 3.6.10, 4.0 > > > S3_PING.validateProperties() has a check to verify that both location and prefix are not set, but the superclass FILE_PING sets the value for location. In order to use prefix, the location property has to be set to null which is not possible in all cases. See ISPN-5097 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1334) Failure on connection not detected.

by Doug Grove (JIRA)

[ https://issues.jboss.org/browse/JBREM-1334?page=com.atlassian.jira.plugin... ] Doug Grove updated JBREM-1334: ------------------------------ Description: Looking at BisocketServerInvoker.run(): {code} if (!t.checkConnection()) { t.shutdown(); synchronized (this) { if (!running) return; controlConnectionThreadMap.remove(listenerId); Object o = controlConnectionRestartsMap.get(listenerId); int restarts = ((Integer)o).intValue(); if (restarts + 1 > controlConnectionRestarts) { log.warn(this + ": detected failure on control connection " + t); log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); log.warn("Assuming it is a connection to an old server, and will not restart"); controlConnectionRestartsMap.remove(listenerId); continue; } log.warn(this + ": detected failure on control connection " + t + " (" + listenerId + ": requesting new control connection"); } {code} It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. was: Lookin at BisocketServerInvoker.run(): {code} if (!t.checkConnection()) { t.shutdown(); synchronized (this) { if (!running) return; controlConnectionThreadMap.remove(listenerId); Object o = controlConnectionRestartsMap.get(listenerId); int restarts = ((Integer)o).intValue(); if (restarts + 1 > controlConnectionRestarts) { log.warn(this + ": detected failure on control connection " + t); log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); log.warn("Assuming it is a connection to an old server, and will not restart"); controlConnectionRestartsMap.remove(listenerId); continue; } log.warn(this + ": detected failure on control connection " + t + " (" + listenerId + ": requesting new control connection"); } {code} It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. > Failure on connection not detected. > ----------------------------------- > > Key: JBREM-1334 > URL: https://issues.jboss.org/browse/JBREM-1334 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP4 > Environment: Red Hat JBoss EAP 5.1.2 > Reporter: Doug Grove > > Looking at BisocketServerInvoker.run(): > {code} > if (!t.checkConnection()) > { > t.shutdown(); > > synchronized (this) > { > if (!running) > return; > > controlConnectionThreadMap.remove(listenerId); > Object o = controlConnectionRestartsMap.get(listenerId); > int restarts = ((Integer)o).intValue(); > > if (restarts + 1 > controlConnectionRestarts) > { > log.warn(this + ": detected failure on control connection " + t); > log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); > log.warn("Assuming it is a connection to an old server, and will not restart"); > controlConnectionRestartsMap.remove(listenerId); > continue; > } > > log.warn(this + ": detected failure on control connection " + t + > " (" + listenerId + > ": requesting new control connection"); > } > {code} > It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1334) Failure on connection not detected.

by Doug Grove (JIRA)

[ https://issues.jboss.org/browse/JBREM-1334?page=com.atlassian.jira.plugin... ] Doug Grove reassigned JBREM-1334: --------------------------------- Assignee: Ron Sigal > Failure on connection not detected. > ----------------------------------- > > Key: JBREM-1334 > URL: https://issues.jboss.org/browse/JBREM-1334 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP4 > Environment: Red Hat JBoss EAP 5.1.2 > Reporter: Doug Grove > Assignee: Ron Sigal > > Looking at BisocketServerInvoker.run(): > {code} > if (!t.checkConnection()) > { > t.shutdown(); > > synchronized (this) > { > if (!running) > return; > > controlConnectionThreadMap.remove(listenerId); > Object o = controlConnectionRestartsMap.get(listenerId); > int restarts = ((Integer)o).intValue(); > > if (restarts + 1 > controlConnectionRestarts) > { > log.warn(this + ": detected failure on control connection " + t); > log.warn("Control connection " + listenerId + " has been recreated " + restarts + " times."); > log.warn("Assuming it is a connection to an old server, and will not restart"); > controlConnectionRestartsMap.remove(listenerId); > continue; > } > > log.warn(this + ": detected failure on control connection " + t + > " (" + listenerId + > ": requesting new control connection"); > } > {code} > It looks like the check never succeeds and " detected failure on control connection " is logged indefinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016