[JBoss JIRA] (WFCORE-3758) start-servers operation can start servers when the host is in admin-only mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3758?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3758:
------------------------------------------
Good catch!
> start-servers operation can start servers when the host is in admin-only mode
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3758
> URL: https://issues.jboss.org/browse/WFCORE-3758
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Yeray Borges
> Assignee: Yeray Borges
>
> If a Host Controler is reloaded or started in admin-only mode, it is possible to start the servers using {{:start-servers}} operation. It is problematic when the user reloads the Host Controller without restarting the servers and tries to start the servers afterwards.
> By definition, when the host controller is started in admin-only, it will not start any server. Indeed, if the user tries to start a single server using {{/host=master/server-config=server-one:start}} an error is correctly reported:
> {code:xml}
> [domain@localhost:9990 /] /host=master/server-config=server-one:start
> {
> "outcome" => "failed",
> "failure-description" => "WFLYHC0048: Cannot start servers when the Host Controller running mode is ADMIN_ONLY",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-344) Create operations to view the host and process controller log files
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-344?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-344:
--------------------------------------
At some point we should probably consider adding the logging subsystem to the host resource. I thought there was already a JIRA for that, but I can't seem to find it. However it might be best to wait until we have a solution for removing the {{logging.properties}} file.
That said the idea for the {{host-controller.log}} was to reuse what is in the logging subsystem for reading log files. I'm not too sure what could or should be done with the {{process-controller.log}}. I haven't put much though into. Currently the HC and PC logs can only be configured via the {{logging.properties}} file. This may always be the case with the PC.
> Create operations to view the host and process controller log files
> -------------------------------------------------------------------
>
> Key: WFCORE-344
> URL: https://issues.jboss.org/browse/WFCORE-344
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Perkins
> Assignee: James Perkins
> Labels: domain-mode
>
> Operations need to exist somewhere so the {{host-controller.log}} and {{process-controller.log}} files can be read with a management operation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-344) Create operations to view the host and process controller log files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-344?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-344:
-----------------------------------------
Good question. Doing a /host=*/subsystem=logging is certainly one way to deal with host-controller.log without adding new code. Perhaps overkill though. It would need to be a Feature of its own though, with this log viewer aspect as just a detail.
However, process-controller.log would not be technically related to any /host=*/subsystem=logging. IOW, what's in such a subsystem would have no impact on the logging behavior of the ProcessController, which is a separate process not managed by the HC. Perhaps the host subsystem could still serve the file though so long as it's in the same dir where the HC writes its logs. I forget what the precise rules are on what files the subsystem log viewer is willing to serve.
> Create operations to view the host and process controller log files
> -------------------------------------------------------------------
>
> Key: WFCORE-344
> URL: https://issues.jboss.org/browse/WFCORE-344
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Perkins
> Assignee: James Perkins
> Labels: domain-mode
>
> Operations need to exist somewhere so the {{host-controller.log}} and {{process-controller.log}} files can be read with a management operation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Dmitrii Tikhomirov (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Dmitrii Tikhomirov reassigned WFLY-10253:
-----------------------------------------
Assignee: Dmitrii Tikhomirov (was: Scott Marlow)
> ConcurrentModificationException on startup
> ------------------------------------------
>
> Key: WFLY-10253
> URL: https://issues.jboss.org/browse/WFLY-10253
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Martin Herschke
> Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-145) Modularize CI/CD Pipline
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-145?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo commented on SWSQE-145:
-----------------------------------------------
[~jkandasa] [~hhovsepy] [~mmahoney]
On the traffic Generator, it is possible o specify some time for traffic to run.
eg: 10 seconds. If you use 0 it will run forever.
I'll add that as an option on Traffic Phase
Does it solve the issue [~jkandasa]?
> Modularize CI/CD Pipline
> ------------------------
>
> Key: SWSQE-145
> URL: https://issues.jboss.org/browse/SWSQE-145
> Project: Kiali QE
> Issue Type: Epic
> Reporter: Matt Mahoney
> Assignee: Guilherme Baufaker Rêgo
> Attachments: Kiali Pipeline Proposal.png
>
>
> The CI/CD pipeline has become more complex and challenging with which to build CI/CD usage-cases and to add new functionality:
> Use Case Examples:
> 1) Deploy Istio -> Deploy&build-kiali -> Deploy All Service Meshes -> Deploy Traffic Generator on all Service Meshes -> Run all test suites
> 2) Deploy built Kiali -> Run REST suite
> 3) Build and Deploy Kiali -> Run all test suites
> 4) Run UI suite on any Openshift Cluster
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3727) NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3727?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3727:
-------------------------------------
Fix Version/s: 5.0.0.Alpha4
> NPE in io.undertow.security.impl.BasicAuthenticationMechanism.authenticate when picketbox subsystem removed
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3727
> URL: https://issues.jboss.org/browse/WFCORE-3727
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ilia Vassilev
> Assignee: Darran Lofthouse
> Fix For: 5.0.0.Alpha4
>
>
> After enabling elytron, the security subsystem was removed. The war using jboss-web.xml security-domain looks like it is not used when the picketbox security subsystem is removed.
> {code}
> java.lang.NullPointerException
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:167)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:330)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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}
> The war has jboss-web.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>other</security-domain>
> </jboss-web>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:undertow:4.0">
> ...
> <application-security-domains>
> <application-security-domain name="other" http-authentication-factory="application-http-authentication"/>
> </application-security-domains>
> </subsystem>
> <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
> ...
> <http>
> <http-authentication-factory name="application-http-authentication" http-server-mechanism-factory="global" security-domain="ApplicationDomain">
> <mechanism-configuration>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="Application Realm"/>
> </mechanism>
> <mechanism mechanism-name="FORM"/>
> </mechanism-configuration>
> </http-authentication-factory>
> <provider-http-server-mechanism-factory name="global"/>
> </http>
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years