January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2023) Log viewer does not show any log file for rpm installation

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2023?page=com.atlassian.jira.plugi... ] Bartosz Baranowski updated WFCORE-2023: --------------------------------------- Fix Version/s: (was: 3.0.0.Alpha13) > Log viewer does not show any log file for rpm installation > ---------------------------------------------------------- > > Key: WFCORE-2023 > URL: https://issues.jboss.org/browse/WFCORE-2023 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Bartosz Baranowski > Assignee: James Perkins > > I'm running a fresh RHEL7.3 server subscribed to the current jboss eap7 repository [1] using the rpm package. [2] > [1] subscription-manager repos --enable=jb-eap-7-for-rhel-RHEL_VERSION-server-rpms > [2] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2118) Start/restart/reload options naming should be consistent for server in standalone and in domain mode

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2118?page=com.atlassian.jira.plugi... ] Stuart Douglas reopened WFCORE-2118: ------------------------------------ > Start/restart/reload options naming should be consistent for server in standalone and in domain mode > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-2118 > URL: https://issues.jboss.org/browse/WFCORE-2118 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Server > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Minor > > As part of EAP 7.1.0.DR9 and [EAP7-636] there was introduced possibility to define that start/reload/restart operation should end up in suspended mode instead of fully starting immediately. > In standalone mode this is controlled via {{start-mode}} parameter. In case of domain mode there are boolean attributes for each of the start options. > It would be nice to be consistent and also in domain use {{start-mode}} parameter (it can be limited to values making sense only in domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2118) Start/restart/reload options naming should be consistent for server in standalone and in domain mode

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2118?page=com.atlassian.jira.plugi... ] Stuart Douglas updated WFCORE-2118: ----------------------------------- Fix Version/s: (was: 3.0.0.Alpha16) > Start/restart/reload options naming should be consistent for server in standalone and in domain mode > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-2118 > URL: https://issues.jboss.org/browse/WFCORE-2118 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Server > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Minor > > As part of EAP 7.1.0.DR9 and [EAP7-636] there was introduced possibility to define that start/reload/restart operation should end up in suspended mode instead of fully starting immediately. > In standalone mode this is controlled via {{start-mode}} parameter. In case of domain mode there are boolean attributes for each of the start options. > It would be nice to be consistent and also in domain use {{start-mode}} parameter (it can be limited to values making sense only in domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication.

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6823: -------------------------------------- In EAP7 it was possible to specify both the default charset, and a per browser charset (based on regex matches of the user agent string). The default charset was UTF-8. > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2167) Wildfly OpenSSL 1.0.0.Beta2

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-2167: -------------------------------------- Summary: Wildfly OpenSSL 1.0.0.Beta2 Key: WFCORE-2167 URL: https://issues.jboss.org/browse/WFCORE-2167 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2166) Wildfly OpenSSL 1.0.0.Beta2

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-2166: -------------------------------------- Summary: Wildfly OpenSSL 1.0.0.Beta2 Key: WFCORE-2166 URL: https://issues.jboss.org/browse/WFCORE-2166 Project: WildFly Core Issue Type: Component Upgrade Reporter: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2166) Wildfly OpenSSL 1.0.0.Beta2

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2166?page=com.atlassian.jira.plugi... ] Stuart Douglas reassigned WFCORE-2166: -------------------------------------- Assignee: Stuart Douglas > Wildfly OpenSSL 1.0.0.Beta2 > --------------------------- > > Key: WFCORE-2166 > URL: https://issues.jboss.org/browse/WFCORE-2166 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2162) Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2162?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2162: ---------------------------------------- Assignee: Darran Lofthouse (was: Brian Stansberry) > Authentication against HTTP management interface with empty username causes Internal Server Error (status 500) > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2162 > URL: https://issues.jboss.org/browse/WFCORE-2162 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha18 > > > In case when empty username is passed during authentication to Management Console then exception is thrown to server log and Internal Server Error (status 500) is returned to user (which leads to displaying "Connect to Management Interface" page. User is not able to try to login again. > In WildFly 10.1.0 this scenario works fine - after passing empty username during authentication, authentication failed and login window is displayed again. I request blocker due to regression. > Exception thrown to server log: > {code} > ERROR [io.undertow.request] (management task-3) UT005071: Undertow request failed HttpServerExchange{ GET /management request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], User-Agent=[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0], Connection=[keep-alive], Authorization=[Digest username="", realm="ManagementRealm", nonce="AAAAAwAAAlzTPVPLC0qPi6CaEhTCHZa+QjsuAjn3OsQXcuDYAxrOtc+rRMs=", uri="/management", algorithm=MD5, response="cbd764e6c09577625476340f7bcfc84d", opaque="00000000000000000000000000000000"], Content-Type=[text/plain; charset=utf-8], Cookie=[__utma=111872281.1874867570.1477040206.1479886566.1479982414.11; __utmz=111872281.1477040206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=111872281.5.10.1479982414; __utmt=1; __utmc=111872281], Referer=[http://localhost:9990/console/App.html], Host=[localhost:9990]} response {X-Frame-Options=[SAMEORIGIN]}}: java.lang.IllegalArgumentException > at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90) > at org.wildfly.security.http.impl.DigestAuthenticationMechanism.getH_A1(DigestAuthenticationMechanism.java:233) > at org.wildfly.security.http.impl.DigestAuthenticationMechanism.validateResponse(DigestAuthenticationMechanism.java:189) > at org.wildfly.security.http.impl.DigestAuthenticationMechanism.evaluateRequest(DigestAuthenticationMechanism.java:121) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2165) Get MSC stability before reinstalling removed services or bouncing services that are starting

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2165: ---------------------------------------- Summary: Get MSC stability before reinstalling removed services or bouncing services that are starting Key: WFCORE-2165 URL: https://issues.jboss.org/browse/WFCORE-2165 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry This task is to implement workarounds for issues like MSC-155 and MSC-156. The MSC issues are manifesting themselves as problems when chains of interdependent deployments are deployed and the deployments depended upon by long chains of dependents are redeployed. The result is an MSC service container that may not reach stability. For example, deployment C.war depends on B.ear which depends on A.ear. Redeploying A.ear will sometimes results in an unstable service container. Specifically this task is to: 1) If a management op removes a service and then later reinstalls the same service (e.g. in a redeploy op, where the service is the root service for the deployment), pause briefly to give MSC a chance to stabilize before doing the install. Note this is just a pause, and there is no guarantee stability will happen in that period, and failure to stabilize should be ignored. This one is purely a workaround. 2) If DeploymentUnitPhaseService detects it is starting a second time, it reacts to that by finding the root service for the deployment, stopping it and then via an MSC listener starting it as soon as stopped. (This is to ensure the full DUP chain runs, as restarting parts of the chain is not reliable in terms of correctly setting things up.) Replace this approach with one where DUPS simply tells the management layer that the deployment needs to be restarted, with the management layer itself taking care of it before completing Stage.RUNTIME. The management layer will await MSC stability before stopping the deployments and will await stability before starting them again. This latter element is not purely a workaround, as there may be benefits to the more coordinated restart this provides beyond avoiding MSC issues. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2162) Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2162?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2162: ---------------------------------------- Assignee: Brian Stansberry (was: Darran Lofthouse) > Authentication against HTTP management interface with empty username causes Internal Server Error (status 500) > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2162 > URL: https://issues.jboss.org/browse/WFCORE-2162 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.0.Alpha18 > > > In case when empty username is passed during authentication to Management Console then exception is thrown to server log and Internal Server Error (status 500) is returned to user (which leads to displaying "Connect to Management Interface" page. User is not able to try to login again. > In WildFly 10.1.0 this scenario works fine - after passing empty username during authentication, authentication failed and login window is displayed again. I request blocker due to regression. > Exception thrown to server log: > {code} > ERROR [io.undertow.request] (management task-3) UT005071: Undertow request failed HttpServerExchange{ GET /management request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], User-Agent=[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0], Connection=[keep-alive], Authorization=[Digest username="", realm="ManagementRealm", nonce="AAAAAwAAAlzTPVPLC0qPi6CaEhTCHZa+QjsuAjn3OsQXcuDYAxrOtc+rRMs=", uri="/management", algorithm=MD5, response="cbd764e6c09577625476340f7bcfc84d", opaque="00000000000000000000000000000000"], Content-Type=[text/plain; charset=utf-8], Cookie=[__utma=111872281.1874867570.1477040206.1479886566.1479982414.11; __utmz=111872281.1477040206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=111872281.5.10.1479982414; __utmt=1; __utmc=111872281], Referer=[http://localhost:9990/console/App.html], Host=[localhost:9990]} response {X-Frame-Options=[SAMEORIGIN]}}: java.lang.IllegalArgumentException > at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90) > at org.wildfly.security.http.impl.DigestAuthenticationMechanism.getH_A1(DigestAuthenticationMechanism.java:233) > at org.wildfly.security.http.impl.DigestAuthenticationMechanism.validateResponse(DigestAuthenticationMechanism.java:189) > at org.wildfly.security.http.impl.DigestAuthenticationMechanism.evaluateRequest(DigestAuthenticationMechanism.java:121) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > 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) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 January 2017