July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1667?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1667: --------------------------------------- Also note the test may require a short sleep before the reads of the hash to ensure the deployment is complete. I've had it fail twice now with unmatched byte arrays. > After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1667 > URL: https://issues.jboss.org/browse/WFCORE-1667 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. > I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78.... Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. > Do note that this test may not be needed, but it was an easy way to show what the issue is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1667?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1667: ---------------------------------- Description: When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78.... Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. Do note that this test may not be needed, but it was an easy way to show what the issue is. was:When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. Steps to Reproduce: See test commit https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78... Summary: After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated (was: After a full-replace-deployment operation on a managed domain in a composite operation the first enabled timestamp is not updated) > After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1667 > URL: https://issues.jboss.org/browse/WFCORE-1667 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. > I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78.... Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. > Do note that this test may not be needed, but it was an easy way to show what the issue is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation the first enabled timestamp is not updated

by James Perkins (JIRA)

James Perkins created WFCORE-1667: ------------------------------------- Summary: After a full-replace-deployment operation on a managed domain in a composite operation the first enabled timestamp is not updated Key: WFCORE-1667 URL: https://issues.jboss.org/browse/WFCORE-1667 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: James Perkins Assignee: Brian Stansberry When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6874) Upgrade jsf-impl to 2.2.13.SP2

by Farah Juma (JIRA)

Farah Juma created WFLY-6874: -------------------------------- Summary: Upgrade jsf-impl to 2.2.13.SP2 Key: WFLY-6874 URL: https://issues.jboss.org/browse/WFLY-6874 Project: WildFly Issue Type: Component Upgrade Components: JSF Reporter: Farah Juma Assignee: Farah Juma This upgrade includes the fix for [JAVASERVERFACES-4130|https://java.net/jira/browse/JAVASERVERFACES-4130]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'

by river shen (JIRA)

[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ] river shen closed WFLY-6671. ---------------------------- the work around is good enough. > ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked' > ----------------------------------------------------------------------------------------- > > Key: WFLY-6671 > URL: https://issues.jboss.org/browse/WFLY-6671 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37 > Reporter: river shen > Assignee: Stuart Douglas > Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties > > > When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior: > if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1. > It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port. > We have attached a minimal web application that reproduce this issue. > Also attached is the standalone.xml and the apache configuration file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6767?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6767: -------------------------------------- Component/s: Security Assignee: Darran Lofthouse > 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 > Components: Security > Reporter: Derek Horton > Assignee: Darran Lofthouse > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6848) In rare circumstances MessageProducer can send a message to wrong queue.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6848?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6848: -------------------------------------- Component/s: JMS Assignee: Jeff Mesnil (was: Jason Greene) > In rare circumstances MessageProducer can send a message to wrong queue. > ------------------------------------------------------------------------ > > Key: WFLY-6848 > URL: https://issues.jboss.org/browse/WFLY-6848 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Bartosz Baranowski > Assignee: Jeff Mesnil > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6846) Redistribution loses large messages when server with HA is restarted

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6846?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6846: -------------------------------------- Component/s: JMS Assignee: Jeff Mesnil (was: Jason Greene) > Redistribution loses large messages when server with HA is restarted > -------------------------------------------------------------------- > > Key: WFLY-6846 > URL: https://issues.jboss.org/browse/WFLY-6846 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Bartosz Baranowski > Assignee: Jeff Mesnil > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6847) Lost large messages if backup is shutdown during synchronization

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6847?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6847: -------------------------------------- Component/s: JMS Assignee: Jeff Mesnil (was: Jason Greene) > Lost large messages if backup is shutdown during synchronization > ---------------------------------------------------------------- > > Key: WFLY-6847 > URL: https://issues.jboss.org/browse/WFLY-6847 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Bartosz Baranowski > Assignee: Jeff Mesnil > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6850) max-saved-replicated-journal-size is ignored

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6850?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6850: ----------------------------------- Component/s: JMS > max-saved-replicated-journal-size is ignored > -------------------------------------------- > > Key: WFLY-6850 > URL: https://issues.jboss.org/browse/WFLY-6850 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Bartosz Baranowski > Assignee: Clebert Suconic > Priority: Critical > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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 July 2016