November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4757) [DMN Designer] Code Completion - Monaco has an odd behaviour when it presents suggestions

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4757: --------------------------------------- Summary: [DMN Designer] Code Completion - Monaco has an odd behaviour when it presents suggestions Key: DROOLS-4757 URL: https://issues.jboss.org/browse/DROOLS-4757 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes Attachments: auto-vs-explicit.webm The attached video demonstrates different behaviors when completions are shown automatically (first 2 attempts) and explicitly (last 2 attempts). It does not seem like the expected behaviour. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4650) GDST: Re-editing BRL columns causes NPE

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4650?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4650: -------------------------------- Fix Version/s: 7.30.0.Final > GDST: Re-editing BRL columns causes NPE > --------------------------------------- > > Key: DROOLS-4650 > URL: https://issues.jboss.org/browse/DROOLS-4650 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > Fix For: 7.30.0.Final > > > The equals and hashcode implementations do not return equal results for BRL columns or equals expects the objects to be the same instance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1006) First attempt to remove ocp 4.2 cluster sometimes fails

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-1006?page=com.atlassian.jira.plugin... ] Filip Brychta commented on SWSQE-1006: -------------------------------------- level=debug msg="Exiting deleting openstack subnets" level=debug msg="Deleting Floating IP: ea28cee4-da66-44a2-a64f-5509af4b67fd" level=debug msg="Deleting container: ocp-jqe2-lzc2g-image-registry-ptmfjgligviifudscepaghxhcthtggmu\n" level=fatal msg="Resource not found" > First attempt to remove ocp 4.2 cluster sometimes fails > ------------------------------------------------------- > > Key: SWSQE-1006 > URL: https://issues.jboss.org/browse/SWSQE-1006 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > level=debug msg="Exiting deleting openstack subnets" > level=debug msg="Deleting Floating IP: a11294c5-a827-4dea-b7c0-f64048176efa" > level=fatal msg="Resource not found" -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1006) First attempt to remove ocp 4.2 cluster sometimes fails

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1006: ------------------------------------ Summary: First attempt to remove ocp 4.2 cluster sometimes fails Key: SWSQE-1006 URL: https://issues.jboss.org/browse/SWSQE-1006 Project: Kiali QE Issue Type: Bug Reporter: Filip Brychta Assignee: Filip Brychta level=debug msg="Exiting deleting openstack subnets" level=debug msg="Deleting Floating IP: a11294c5-a827-4dea-b7c0-f64048176efa" level=fatal msg="Resource not found" -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-257) SSO layer cannot be properly used with SSO template

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-257?page=com.atlassian.jira.plugin.... ] Jean Francois Denise commented on WFWIP-257: -------------------------------------------- Elytron doesn't behave the same way as with legacy security domain. When "other" is set, a check is done for the KEYCLOAK mecchanisms. So it fails when provisioning galleon layers (base layer set the "other" security domain). This is very specific to the "other" security domain. If a "keycloak" application-security-domain is set, then, even if the war doesn't specify a security domain, keycloak will be enabled (thanks to the subsystem). We have 4 ways (at least as I see it): 1) Document that, when using Galleon base layers in combination with sso layer, one need to specify a security domain in his deployment. This would break the sso test for galleon. This seems acceptable. 2) Remove the existing "other" application-security-domain and replace it with one that understand keycloak, other mechanisms (BASIC, FORM) would be lost. Is it acceptable to to disable other security mechanisms when keycloak is enable? This is not compliant with legacy behavior for which all mechanisms are available once keycloak is enabled. 3) We could remove "other" and only add the "keycloak: security domain. Security other than keyCloak is disabled. Not what we want. 4) We can detect that "other" is set and references the security--domain "ApplicationDomain". Only in this case (because we know how to reconstruct it with common mechanisms BASIC, FORM) we would remove "other", create new elytron SecurityDomain with keycloak and ApplicationDomain realms, create a new http-authentication-factory that aggregates FORM,BASIC with KEYCLOAK mechanisms (OIDC and SAML) and add "other" referencing the http-authentication-factory. My preference is 4). I discussed with [~fjuma] and this seems doable. I am currently investigating it. [~mjurc], [~brian.stansberry], [~jmesnil] any input? > SSO layer cannot be properly used with SSO template > ---------------------------------------------------- > > Key: WFWIP-257 > URL: https://issues.jboss.org/browse/WFWIP-257 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Michal Jurc > Assignee: Jean Francois Denise > Priority: Blocker > > Currently available OpenShift templates for EAP CD are not able to properly configure EAP server with SSO client, resulting in the following errors: > {code}15:55:01,843 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 38) MSC000001: Failed to start service jboss.deployment.unit."app-profile-jsp.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."app-profile-jsp.war".undertow-deployment: java.lang.RuntimeException: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory. > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory. > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78) > ... 8 more > Caused by: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory. > at org.wildfly.security.elytron-web.undertow-server-servlet@1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.initialSecurityHandler(AuthenticationManager.java:153) > at org.wildfly.security.elytron-web.undertow-server-servlet@1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.lambda$configure$2(AuthenticationManager.java:98) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:442) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:121) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:224) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252) > ... 10 more{code} > I am marking this issue as blocker since the template is currently the only documented way for EAP to use SSO client on OpenShift. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4689) [DMN Designer] Code Completion - Setup Monaco (loader)

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4689?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4689: -------------------------------- Attachment: context-completions.webm > [DMN Designer] Code Completion - Setup Monaco (loader) > ------------------------------------------------------ > > Key: DROOLS-4689 > URL: https://issues.jboss.org/browse/DROOLS-4689 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: auto-vs-explicit.webm, completion-twice.webm, completions-tabulator.webm, context-completions.webm, last-entry-completion.webm > > > Setup Monaco library (and it's loader) into the DMN webapp. > ⚠️ Notice: test it in all environments (dev-webapp, VSCode webapp, Business Central webapp) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1005) Health Tooltip automation

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1005: ------------------------------------- Summary: Health Tooltip automation Key: SWSQE-1005 URL: https://issues.jboss.org/browse/SWSQE-1005 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Read the Health tooltip for App, Workload and Service in lists. Validate via comparison with REST. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-957) Wildfly not respecting subdeployment dependency order

by Katarina Hermanova (Jira)

[ https://issues.jboss.org/browse/WFCORE-957?page=com.atlassian.jira.plugin... ] Katarina Hermanova resolved WFCORE-957. --------------------------------------- Resolution: Explained > Wildfly not respecting subdeployment dependency order > ----------------------------------------------------- > > Key: WFCORE-957 > URL: https://issues.jboss.org/browse/WFCORE-957 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Brian Riehman > Assignee: Katarina Hermanova > Priority: Minor > Attachments: wildfly-deployment-order.ear, wildfly-deployment-order.tar.gz > > > When loading an EAR with {{initialize-in-order}} set to {{true}} within the {{application.xml}} and subdeployment dependencies defined in{{jboss-deployment-structure.xml}}, Wildfly does not load the EAR modules in order as specified nor as defined by the dependencies. > I have attached both a [source repository|https://github.com/briehman/wildfly-deployment-order] and the generated EAR. The {{application.xml}} and {{jboss-deployment-structure.xml}} are as below: > {code} > <?xml version="1.0" encoding="UTF-8"?> > <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd" version="6"> > <display-name>ear</display-name> > <initialize-in-order>true</initialize-in-order> > <module> > <web> > <web-uri>webapp-one-1.0-SNAPSHOT.war</web-uri> > <context-root>/one</context-root> > </web> > </module> > <module> > <web> > <web-uri>webapp-two-1.0-SNAPSHOT.war</web-uri> > <context-root>/two</context-root> > </web> > </module> > <module> > <web> > <web-uri>webapp-three-1.0-SNAPSHOT.war</web-uri> > <context-root>/three</context-root> > </web> > </module> > </application> > {code} > {code} > <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> > <sub-deployment name="webapp-one-1.0-SNAPSHOT.war"> > </sub-deployment> > <sub-deployment name="webapp-two-1.0-SNAPSHOT.war"> > <dependencies> > <module name="deployment.wildfly-deployment-order.ear.webapp-one-1.0-SNAPSHOT.war" /> > </dependencies> > </sub-deployment> > <sub-deployment name="webapp-three-1.0-SNAPSHOT.war"> > <dependencies> > <module name="deployment.wildfly-deployment-order.ear.webapp-two-1.0-SNAPSHOT.war" /> > </dependencies> > </sub-deployment> > </jboss-deployment-structure> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-957) Wildfly not respecting subdeployment dependency order

by Katarina Hermanova (Jira)

[ https://issues.jboss.org/browse/WFCORE-957?page=com.atlassian.jira.plugin... ] Katarina Hermanova commented on WFCORE-957: ------------------------------------------- This issue was already discussed here: https://stackoverflow.com/questions/32402716/how-can-i-get-wildfly-to-loa... > Wildfly not respecting subdeployment dependency order > ----------------------------------------------------- > > Key: WFCORE-957 > URL: https://issues.jboss.org/browse/WFCORE-957 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Brian Riehman > Assignee: Katarina Hermanova > Priority: Minor > Attachments: wildfly-deployment-order.ear, wildfly-deployment-order.tar.gz > > > When loading an EAR with {{initialize-in-order}} set to {{true}} within the {{application.xml}} and subdeployment dependencies defined in{{jboss-deployment-structure.xml}}, Wildfly does not load the EAR modules in order as specified nor as defined by the dependencies. > I have attached both a [source repository|https://github.com/briehman/wildfly-deployment-order] and the generated EAR. The {{application.xml}} and {{jboss-deployment-structure.xml}} are as below: > {code} > <?xml version="1.0" encoding="UTF-8"?> > <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd" version="6"> > <display-name>ear</display-name> > <initialize-in-order>true</initialize-in-order> > <module> > <web> > <web-uri>webapp-one-1.0-SNAPSHOT.war</web-uri> > <context-root>/one</context-root> > </web> > </module> > <module> > <web> > <web-uri>webapp-two-1.0-SNAPSHOT.war</web-uri> > <context-root>/two</context-root> > </web> > </module> > <module> > <web> > <web-uri>webapp-three-1.0-SNAPSHOT.war</web-uri> > <context-root>/three</context-root> > </web> > </module> > </application> > {code} > {code} > <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> > <sub-deployment name="webapp-one-1.0-SNAPSHOT.war"> > </sub-deployment> > <sub-deployment name="webapp-two-1.0-SNAPSHOT.war"> > <dependencies> > <module name="deployment.wildfly-deployment-order.ear.webapp-one-1.0-SNAPSHOT.war" /> > </dependencies> > </sub-deployment> > <sub-deployment name="webapp-three-1.0-SNAPSHOT.war"> > <dependencies> > <module name="deployment.wildfly-deployment-order.ear.webapp-two-1.0-SNAPSHOT.war" /> > </dependencies> > </sub-deployment> > </jboss-deployment-structure> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11868) Documentation for Rest integration with WildFly Elytron - AuthenticationClient for Authentication / SSL

by Diana Vilkolakova (Jira)

[ https://issues.jboss.org/browse/WFLY-11868?page=com.atlassian.jira.plugin... ] Diana Vilkolakova updated WFLY-11868: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/12802, https://github.com/wildfly/wildfly-proposals/pull/189 (was: https://github.com/wildfly/wildfly-proposals/pull/189) > Documentation for Rest integration with WildFly Elytron - AuthenticationClient for Authentication / SSL > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-11868 > URL: https://issues.jboss.org/browse/WFLY-11868 > Project: WildFly > Issue Type: Feature Request > Components: REST, Security > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > Labels: EAP-CD19 > Fix For: 19.0.0.Beta1 > > > This feature request is about making use of authentication configuration on the client side of the REST deployment. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 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 November 2019