July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally

by Martin Choma (Jira)

Martin Choma created WFWIP-167: ---------------------------------- Summary: EAP Operator handling ConfigMap internally Key: WFWIP-167 URL: https://issues.jboss.org/browse/WFWIP-167 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Martin Choma Assignee: Jeff Mesnil If I understand description in [1] correctly. To specify custom standalone.xml I have to create ConfigMap with standalone.xml first and afterwards link operator to this ConfigMap. Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally I just specify file URI where custom standalone.xml is located. This location have to be accessible from operator pod. In this way we can look at it as hiding internals (implementation details) from users. Currently when user wants to change standalone.xml he does in ConfigMap, not operator. When changing standalone.xml through config map, I assume pod have to be restarted manually. Operator could do that for me. However this can be triggered by storing newer version of standalone.xml under another key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator. What do you think? Have you considered this approach? [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12295) Deployments fails if de.odysseus.juel is included in the war

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12295?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12295: ----------------------------------- Labels: downstream_dependency (was: ) > Deployments fails if de.odysseus.juel is included in the war > ------------------------------------------------------------- > > Key: WFLY-12295 > URL: https://issues.jboss.org/browse/WFLY-12295 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Major > Labels: downstream_dependency > > If the war file contains spring-mvc and de.odysseus.juel in WEB-INF/lib, the deployment fails with the following message. The deployment is successful on EAP7.0.9 and EAP7.1.0, but it fails on EAP7.2.x. > This behavior breaks backward compatibility between EAP7.1 and EAP7.2. > {noformat} > 14:55:59,808 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 73) MSC000001: Failed to start service jboss.deployment.unit."reproduce.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."reproduce.war".undertow-deployment: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78) > ... 8 more > Caused by: java.lang.RuntimeException: java.lang.NullPointerException > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:315) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:216) > at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:185) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:250) > ... 10 more > Caused by: java.lang.NullPointerException > at javax.el.CompositeELResolver.add(CompositeELResolver.java:117) > at com.sun.faces.el.DemuxCompositeELResolver.addRootELResolver(DemuxCompositeELResolver.java:142) > at com.sun.faces.el.ELUtils.addEL3_0_Resolvers(ELUtils.java:336) > at com.sun.faces.el.ELUtils.buildFacesResolver(ELUtils.java:258) > at com.sun.faces.application.ApplicationAssociate.initializeELResolverChains(ApplicationAssociate.java:503) > at com.sun.faces.application.ApplicationImpl.performOneTimeELInitialization(ApplicationImpl.java:1405) > at com.sun.faces.application.ApplicationImpl.getELResolver(ApplicationImpl.java:529) > at javax.faces.application.ApplicationWrapper.getELResolver(ApplicationWrapper.java:621) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:256) > ... 21 more > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12336) Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12336?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12336: ----------------------------------- Component/s: JSF > Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render > ----------------------------------------------------------------------------- > > Key: WFLY-12336 > URL: https://issues.jboss.org/browse/WFLY-12336 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 17.0.1.Final > Reporter: Martin Stefanko > Assignee: Teresa Miyar Gil > Priority: Major > Labels: downstream_dependency > Attachments: reproducer2.war > > > Fix required for Mojarra Issue 4388 / Scripts with CDATA cause "empty response" error on Ajax render > Ref: https://github.com/javaserverfaces/mojarra/issues/4388 > -- > The RenderKitImpl (com.sun.jsf-impl) class is returning a wrong configured ResponseWriter on partial responses. It is breaking the xhtml when it contains a javascript with CDATA; the final xhtml has a bad closed nested CDATAs. > The JSF 2.2.15 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.2.15/jsf-ri/src/main/ja... > The JSF 2.3.5 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.3.5/jsf-ri/src/main/jav... > The issue was introduced with the following commits: > https://github.com/javaserverfaces/mojarra/commit/8a5a562e129a31f3655de86... > https://github.com/javaserverfaces/mojarra/commit/ee3671db95986395e3a40a5... > The issue is fixed on JSF 2.3.9 reverting those above commits. > https://github.com/javaserverfaces/mojarra/issues/4358#issuecomment-44009... > Apply: > https://github.com/javaserverfaces/mojarra/commit/cebcd9bd41f562ec02450d5... > https://github.com/javaserverfaces/mojarra/commit/954773aa256b68e744ae917... > Final class: > https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_3X_ROLLING/jsf-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12336) Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12336?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12336: ----------------------------------- Affects Version/s: 17.0.1.Final > Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render > ----------------------------------------------------------------------------- > > Key: WFLY-12336 > URL: https://issues.jboss.org/browse/WFLY-12336 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 17.0.1.Final > Reporter: Martin Stefanko > Assignee: Teresa Miyar Gil > Priority: Major > Labels: downstream_dependency > Attachments: reproducer2.war > > > Fix required for Mojarra Issue 4388 / Scripts with CDATA cause "empty response" error on Ajax render > Ref: https://github.com/javaserverfaces/mojarra/issues/4388 > -- > The RenderKitImpl (com.sun.jsf-impl) class is returning a wrong configured ResponseWriter on partial responses. It is breaking the xhtml when it contains a javascript with CDATA; the final xhtml has a bad closed nested CDATAs. > The JSF 2.2.15 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.2.15/jsf-ri/src/main/ja... > The JSF 2.3.5 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.3.5/jsf-ri/src/main/jav... > The issue was introduced with the following commits: > https://github.com/javaserverfaces/mojarra/commit/8a5a562e129a31f3655de86... > https://github.com/javaserverfaces/mojarra/commit/ee3671db95986395e3a40a5... > The issue is fixed on JSF 2.3.9 reverting those above commits. > https://github.com/javaserverfaces/mojarra/issues/4358#issuecomment-44009... > Apply: > https://github.com/javaserverfaces/mojarra/commit/cebcd9bd41f562ec02450d5... > https://github.com/javaserverfaces/mojarra/commit/954773aa256b68e744ae917... > Final class: > https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_3X_ROLLING/jsf-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12336) Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12336?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12336: ----------------------------------- Labels: downstream_dependency (was: ) > Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render > ----------------------------------------------------------------------------- > > Key: WFLY-12336 > URL: https://issues.jboss.org/browse/WFLY-12336 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 17.0.1.Final > Reporter: Martin Stefanko > Assignee: Teresa Miyar Gil > Priority: Major > Labels: downstream_dependency > Attachments: reproducer2.war > > > Fix required for Mojarra Issue 4388 / Scripts with CDATA cause "empty response" error on Ajax render > Ref: https://github.com/javaserverfaces/mojarra/issues/4388 > -- > The RenderKitImpl (com.sun.jsf-impl) class is returning a wrong configured ResponseWriter on partial responses. It is breaking the xhtml when it contains a javascript with CDATA; the final xhtml has a bad closed nested CDATAs. > The JSF 2.2.15 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.2.15/jsf-ri/src/main/ja... > The JSF 2.3.5 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.3.5/jsf-ri/src/main/jav... > The issue was introduced with the following commits: > https://github.com/javaserverfaces/mojarra/commit/8a5a562e129a31f3655de86... > https://github.com/javaserverfaces/mojarra/commit/ee3671db95986395e3a40a5... > The issue is fixed on JSF 2.3.9 reverting those above commits. > https://github.com/javaserverfaces/mojarra/issues/4358#issuecomment-44009... > Apply: > https://github.com/javaserverfaces/mojarra/commit/cebcd9bd41f562ec02450d5... > https://github.com/javaserverfaces/mojarra/commit/954773aa256b68e744ae917... > Final class: > https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_3X_ROLLING/jsf-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12336) Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12336?page=com.atlassian.jira.plugin... ] Martin Stefanko moved JBEAP-17307 to WFLY-12336: ------------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12336 (was: JBEAP-17307) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Target Release: (was: 7.backlog.GA) > Mojarra 4596 - Scripts with CDATA cause "empty response" error on Ajax render > ----------------------------------------------------------------------------- > > Key: WFLY-12336 > URL: https://issues.jboss.org/browse/WFLY-12336 > Project: WildFly > Issue Type: Bug > Reporter: Martin Stefanko > Assignee: Teresa Miyar Gil > Priority: Major > Attachments: reproducer2.war > > > Fix required for Mojarra Issue 4388 / Scripts with CDATA cause "empty response" error on Ajax render > Ref: https://github.com/javaserverfaces/mojarra/issues/4388 > -- > The RenderKitImpl (com.sun.jsf-impl) class is returning a wrong configured ResponseWriter on partial responses. It is breaking the xhtml when it contains a javascript with CDATA; the final xhtml has a bad closed nested CDATAs. > The JSF 2.2.15 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.2.15/jsf-ri/src/main/ja... > The JSF 2.3.5 RenderKitImpl: https://github.com/javaserverfaces/mojarra/blob/2.3.5/jsf-ri/src/main/jav... > The issue was introduced with the following commits: > https://github.com/javaserverfaces/mojarra/commit/8a5a562e129a31f3655de86... > https://github.com/javaserverfaces/mojarra/commit/ee3671db95986395e3a40a5... > The issue is fixed on JSF 2.3.9 reverting those above commits. > https://github.com/javaserverfaces/mojarra/issues/4358#issuecomment-44009... > Apply: > https://github.com/javaserverfaces/mojarra/commit/cebcd9bd41f562ec02450d5... > https://github.com/javaserverfaces/mojarra/commit/954773aa256b68e744ae917... > Final class: > https://github.com/javaserverfaces/mojarra/blob/MOJARRA_2_3X_ROLLING/jsf-... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4587) Clarify description of 'maximum-cert-path'

by Jan Stourac (Jira)

Jan Stourac created WFCORE-4587: ----------------------------------- Summary: Clarify description of 'maximum-cert-path' Key: WFCORE-4587 URL: https://issues.jboss.org/browse/WFCORE-4587 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 10.0.0.Beta2 Reporter: Jan Stourac Assignee: Darran Lofthouse Trivial extension of 'maximum-cert-path' attribute of trust-manager to give message when this value actually takes any effect - only if OCSP or CRL are configured. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-775) Identify uncovered areas

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-775?page=com.atlassian.jira.plugin.... ] Filip Brychta reassigned SWSQE-775: ----------------------------------- Assignee: Filip Brychta > Identify uncovered areas > ------------------------ > > Key: SWSQE-775 > URL: https://issues.jboss.org/browse/SWSQE-775 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > > We have the code coverage report so we should be able to identify uncovered areas and create tasks to implement automation. > Also we need to check if all files in the report are expected (remove mock/test data files) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-854) Increase code coverage above 80% (REST tests)

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-854?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-854: -------------------------------- Description: There will be sub task for each package which is not covered at least by 80% For each sub task you can: * add new tests to increase coverage above 80% * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80% * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report See chapter How to get the latest code coverage in https://docs.jboss.org/display/SWSQE/Code+coverage+for+system+tests to generate the latest code coverage. was: There will be sub task for each package which is not covered at least by 80% For each sub task you can: * add new tests to increase coverage above 80% * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80% * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report TODO: add description how to check code coverage > Increase code coverage above 80% (REST tests) > --------------------------------------------- > > Key: SWSQE-854 > URL: https://issues.jboss.org/browse/SWSQE-854 > Project: Kiali QE > Issue Type: Story > Reporter: Filip Brychta > Priority: Major > Labels: automation > > There will be sub task for each package which is not covered at least by 80% > For each sub task you can: > * add new tests to increase coverage above 80% > * add new tests to increase coverage below 80% with comment why it's not possible to achieve 80% > * close the sub task with comment why it's not possible to cover it by tests so it should be excluded from the coverage report > See chapter How to get the latest code coverage in https://docs.jboss.org/display/SWSQE/Code+coverage+for+system+tests to generate the latest code coverage. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12312) Mojarra Issue 3042 / Partial rendering: insufficient CDATA encoding (XSS)

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12312?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12312: ----------------------------------- Labels: downstream_dependency regression (was: regression) > Mojarra Issue 3042 / Partial rendering: insufficient CDATA encoding (XSS) > -------------------------------------------------------------------------- > > Key: WFLY-12312 > URL: https://issues.jboss.org/browse/WFLY-12312 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Major > Labels: downstream_dependency, regression > > Fix required for Mojarra Issue 3042 / Partial rendering: insufficient CDATA encoding (XSS) > Ref: https://github.com/eclipse-ee4j/mojarra/issues/4392 -- This message was sent by Atlassian Jira (v7.12.1#712002)

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