June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1180) Red Hat Operators Mirroring is not working on Disconnected Clusters

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1180?page=com.atlassian.jira.plugi... ] Filip Brychta updated SWSQE-1180: --------------------------------- Labels: infrastructure (was: ) Sprint: Kiali Sprint #41 > Red Hat Operators Mirroring is not working on Disconnected Clusters > ------------------------------------------------------------------- > > Key: SWSQE-1180 > URL: https://issues.redhat.com/browse/SWSQE-1180 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > Attachments: Captura de Tela 2020-06-16 às 20.07.23.png > > > [https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/infra-jobs/job...] > > [https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/install-ocp-upi...] > > Failed to pull image "bastion.gbaufake-disconnected.maistra.upshift.redhat.com:55555/olm/redhat-operators:v1": rpc error: code = Unknown desc = Error reading manifest v1 in bastion.gbaufake-disconnected.maistra.upshift.redhat.com:55555/olm/redhat-operators: manifest unknown: manifest unknown > > > It seems the mirroring is not working on the PSI cluster with the mirror job. > picture attached. > > > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-1180) Red Hat Operators Mirroring is not working on Disconnected Clusters

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1180?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1180. ---------------------------------- Resolution: Done The issue you saw is caused by a recent OCP bug - https://bugzilla.redhat.com/show_bug.cgi?id=1838375 I added a workaround to the mirroring job. > Red Hat Operators Mirroring is not working on Disconnected Clusters > ------------------------------------------------------------------- > > Key: SWSQE-1180 > URL: https://issues.redhat.com/browse/SWSQE-1180 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > Attachments: Captura de Tela 2020-06-16 às 20.07.23.png > > > [https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/view/infra-jobs/job...] > > [https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/install-ocp-upi...] > > Failed to pull image "bastion.gbaufake-disconnected.maistra.upshift.redhat.com:55555/olm/redhat-operators:v1": rpc error: code = Unknown desc = Error reading manifest v1 in bastion.gbaufake-disconnected.maistra.upshift.redhat.com:55555/olm/redhat-operators: manifest unknown: manifest unknown > > > It seems the mirroring is not working on the PSI cluster with the mirror job. > picture attached. > > > > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13592) [GSS] (7.3.z) jndi-view doen't show values for EJB in java:jboss/exported

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-13592?page=com.atlassian.jira.plugi... ] Parul Sharma moved JBEAP-19712 to WFLY-13592: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13592 (was: JBEAP-19712) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Naming (was: EJB) (was: Naming) Affects Version/s: (was: 7.3.0.GA) Fix Version/s: (was: 7.3.3.GA) > [GSS] (7.3.z) jndi-view doen't show values for EJB in java:jboss/exported > ------------------------------------------------------------------------- > > Key: WFLY-13592 > URL: https://issues.redhat.com/browse/WFLY-13592 > Project: WildFly > Issue Type: Bug > Components: EJB, Naming > Reporter: Parul Sharma > Assignee: Parul Sharma > Priority: Major > > jndi-view() show values as '?' for EJB on java:jboss/exported tree. > These values could be seen on EAP 6.4. > This can be reproduced on EAP 7.3.1 and 7.2.8. > I attached a reproducer and these results as follows. > reproducer.zip > jndi_view_result_731.txt > jndi_view_result_6422.txt > > EAP 7.3.1 / 7.2.8 > {code} > [standalone@localhost:9990 /] /subsystem=naming:jndi-view() > ... > "java:jboss/exported" => { > "ejb2-1.0" => { > "class-name" => "javax.naming.Context", > "children" => { > "GreeterEJB!com.example.GreeterEJBHome" => { > "class-name" => "java.lang.Object", > "value" => "?" > }, > "GreeterEJB!com.example.GreeterEJBRemote" => { > "class-name" => "java.lang.Object", > "value" => "?" > } > } > }, > "ejb3-1.0" => { > "class-name" => "javax.naming.Context", > "children" => {"GreeterEJB!com.example.GreeterRemote" => { > "class-name" => "java.lang.Object", > "value" => "?" > }} > } > }, > {code} > > EAP 6.4 > {code} > "java:jboss/exported" => { > "ejb2-1.0" => { > "class-name" => "javax.naming.Context", > "children" => { > "GreeterEJB!com.example.GreeterEJBHome" => { > "class-name" => "com.example.GreeterEJBHome", > "value" => "Proxy for remote EJB EJBHomeLocator{appName='', moduleName='ejb2-1.0', distinctName='', beanName='GreeterEJB', view='interface com.example.GreeterEJBHome'}" > }, > "GreeterEJB!com.example.GreeterEJBRemote" => { > "class-name" => "com.example.GreeterEJBRemote", > "value" => "Proxy for remote EJB StatelessEJBLocator{appName='', moduleName='ejb2-1.0', distinctName='', beanName='GreeterEJB', view='interface com.example.GreeterEJBRemote'}" > } > } > }, > "ejb3-1.0" => { > "class-name" => "javax.naming.Context", > "children" => {"GreeterEJB!com.example.GreeterRemote" => { > "class-name" => "com.example.GreeterRemote", > "value" => "Proxy for remote EJB StatelessEJBLocator{appName='', moduleName='ejb3-1.0', distinctName='', beanName='GreeterEJB', view='interface com.example.GreeterRemote'}" > }} > } > }, > {code} > > Additionally, > If EJB3 doesn't have @Remote, values are '?' in 'java:global' and 'java:app' similarly. > The following behaviour is not changed from 6.4. But it seems a sililar behavir as the above. > I attached the reproducer and these results as follows. > reproducer_without_remote_if.zip > jndi_view_result_no_remoteif_731.txt > jndi_view_result_no_remoteif_6422.txt > EAP 7.3.1 > {code} > "java:global" => { > ... > "ejb3-1.0" => { > "class-name" => "javax.naming.Context", > "children" => { > "GreeterEJB" => { > "class-name" => "com.example.GreeterEJB", > "value" => "?" > }, > "GreeterEJB!com.example.GreeterEJB" => { > "class-name" => "com.example.GreeterEJB", > "value" => "?" > } > } > } > } > }, > "applications" => { > "ejb3-1.0.jar" => { > "java:app" => { > ... > "ejb3-1.0" => { > "class-name" => "javax.naming.Context", > "children" => { > "GreeterEJB" => { > "class-name" => "com.example.GreeterEJB", > "value" => "?" > }, > "GreeterEJB!com.example.GreeterEJB" => { > "class-name" => "com.example.GreeterEJB", > "value" => "?" > } > } > } > }, > "modules" => undefined > }, > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-1182) DropDown - Optimization of hierarchy.

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1182: ------------------------------------- Summary: DropDown - Optimization of hierarchy. Key: SWSQE-1182 URL: https://issues.redhat.com/browse/SWSQE-1182 Project: Kiali QE Issue Type: Bug Reporter: Hayk Hovsepyan Currently there is a big hierarchy of DropDown objects. It needs to be optimized. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-1181) DropDown - Check open and close states first - optimize

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1181: ------------------------------------- Summary: DropDown - Check open and close states first - optimize Key: SWSQE-1181 URL: https://issues.redhat.com/browse/SWSQE-1181 Project: Kiali QE Issue Type: Bug Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5438) DMN align FEEL behaviour when sum([])

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5438: -------------------------------------- Summary: DMN align FEEL behaviour when sum([]) Key: DROOLS-5438 URL: https://issues.redhat.com/browse/DROOLS-5438 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Attachments: image-2020-06-17-12-38-33-381.png from the DMN spec !image-2020-06-17-12-38-33-381.png! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2484) SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/JGRP-2484?page=com.atlassian.jira.plugin... ] Tristan Tarrant commented on JGRP-2484: --------------------------------------- I can provide a backport > SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL > ------------------------------------------------- > > Key: JGRP-2484 > URL: https://issues.redhat.com/browse/JGRP-2484 > Project: JGroups > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 5.0.0.Final > > > WildFly OpenSSL provides a high-performance implementation of SSLContext. > While SSL_KEY_EXCHANGE supports passing custom SSLContext instances through the programmatic API, this is not possible through the declarative API. > It should be possible to detect the presence of WildFly OpenSSL on the classpath and use it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2484) SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/JGRP-2484?page=com.atlassian.jira.plugin... ] Tristan Tarrant reassigned JGRP-2484: ------------------------------------- Assignee: Tristan Tarrant (was: Bela Ban) > SSL_KEY_EXCHANGE: Add support for WildFly OpenSSL > ------------------------------------------------- > > Key: JGRP-2484 > URL: https://issues.redhat.com/browse/JGRP-2484 > Project: JGroups > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 5.0.0.Final > > > WildFly OpenSSL provides a high-performance implementation of SSLContext. > While SSL_KEY_EXCHANGE supports passing custom SSLContext instances through the programmatic API, this is not possible through the declarative API. > It should be possible to detect the presence of WildFly OpenSSL on the classpath and use it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1998) IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11

by Diana Vilkolakova (Jira)

[ https://issues.redhat.com/browse/ELY-1998?page=com.atlassian.jira.plugin.... ] Diana Vilkolakova commented on ELY-1998: ---------------------------------------- [~fjuma] I tried it but the exception stays the same. > IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available when configuring BC FIPS on JDK 11 > --------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1998 > URL: https://issues.redhat.com/browse/ELY-1998 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Diana Vilkolakova > Priority: Major > > The below steps require ELY-1982 bugfix to work. > Configure security providers in java.security file: > {code} > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider > security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider > security.provider.3=SUN > {code} > Add the bc-fips.jar and bctls-fips-1.0.10.jar to the CLASSPATH and generate keystore in JBOSS_HOME/standalone/configuration folder: > {code} > keytool -genkeypair -alias appserver -keyalg RSA -keysize 2048 -keypass password -keystore "fips.keystore" -provider org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -providerpath $CLASSPATH -storetype BCFKS -storepass password -dname "CN=testserver,OU=TESTOU,O=TESTO,L=TESTL,ST=TESTCZ,C=TESTCZ" -validity 730 -v > {code} > Try to configure `server-ssl-context`: > {code} > module add --name=org.bouncycastle.fips --resources=/path/to/bc-fips-1.0.2.jar:/path/to/bctls-fips-1.0.10.jar > /subsystem=elytron/provider-loader=bc:add(module=org.bouncycastle.fips) > /subsystem=elytron/key-store=fipsKS:add(path=fips.keystore, relative-to=jboss.server.config.dir, credential-reference={clear-text=password}, type="BCFKS", providers=bc) > /subsystem=elytron/key-manager=fipsKM:add(key-store=fipsKS, algorithm="X509", credential-reference={clear-text=password}, providers=bc) > /subsystem=elytron/server-ssl-context=fipsSSC:add(key-manager=fipsKM, protocols=["TLSv1.2"], providers=bc) > {code} > The last command results in: > {code} > { > "outcome" => "failed", > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.fipsSSC" => "Failed to start service > Caused by: java.lang.IllegalStateException: unable to create JcaTlsCrypto: DEFAULT SecureRandom not available > Caused by: java.security.NoSuchAlgorithmException: DEFAULT SecureRandom not available"}}, > "rolled-back" => true > } > {code} > The exception is happening [on this line|https://github.com/Skyllarr/wildfly-elytron/blob/ELY-1982/ssl/src/ma...] . This exception can be avoided by either using *new SecureRandom()* instead of null during initialization of sslContext, or by configuring securerandom with using *CryptoServicesRegistrar.setSecureRandom(new SecureRandom());* in code beforehand (this would require bc dependency). > I tried to configure secure random statically by setting *securerandom.strongAlgorithms=DEFAULT:BCFIPS* in java.security or by trying to pass secure random as parameter to constructor with > {code} > security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider "C:DEFRND[SHA512];ENABLE{ALL};" > {code} > but neither had any effect. I did not find how to configure this statically for Java 11 in BC documentation. > We could pass new instance of SecureRandom when initializing sslContext (if bouncycastle is used), or set secureRandom beforehand, or catch this exception and then use `new SecureRandom()`. But should we force the users to use SecureRandom set in the code by us? If users want to use Bouncycastle they should configure the secure random themselves since it is needed by the provider? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-5010) Startup error messages caused by expression where expressions are not allowed are confusing

by Lukas Vydra (Jira)

[ https://issues.redhat.com/browse/WFCORE-5010?page=com.atlassian.jira.plug... ] Lukas Vydra moved WFLY-6938 to WFCORE-5010: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-5010 (was: WFLY-6938) Component/s: Server (was: Server) Affects Version/s: (was: 10.1.0.CR1) > Startup error messages caused by expression where expressions are not allowed are confusing > ------------------------------------------------------------------------------------------- > > Key: WFCORE-5010 > URL: https://issues.redhat.com/browse/WFCORE-5010 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Ondrej Chaloupka > Assignee: Lukas Vydra > Priority: Minor > > When a property expression is used at place where expression usage is not allowed then error message which is shown is quite confusing. From user point of view (especially the newcomer) it would be nice if the error message shows the real reason - usage of expression at place where is not permitted. > Maybe CLI could warn on usage of expression on place where is not allowed too. > Documentation recommends configuration with CLI, editing of XML file is common too. More of it there are some tasks which are harder to be done with CLI and editing XML is faster/easier. > Examples: > Setting > {code} > /subsystem=ee/managed-executor-service=default:write-attribute(name=context-service, value="${my.context.service}") > {code} > ends with this error message during startup > {code} > 14:13:21,076 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "ee"), > ("managed-executor-service" => "default") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.concurrent.ee.context.service.${my.context.service}"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.concurrent.ee.executor.default is missing [jboss.concurrent.ee.context.service.${my.context.service}]"]} > {code} > another confusion is setting name of host in {{host-slave.xml}} file. When set as > {code} > <host xmlns="urn:jboss:domain:4.2" host="${host.name}"> > {code} > then NullPointerException is thrown. > {code} > [Host Controller] 14:18:45,238 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:188) > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:594) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > at java.lang.Thread.run(Thread.java:745)[Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError > at [row,col]:[3,1][Host Controller] Message: WFLYCTL0197: Unexpected attribute 'host' encountered > at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117) > at org.jboss.as.host.controller.parsing.HostXml_4.readHostElement(HostXml_4.java:311) > at org.jboss.as.host.controller.parsing.HostXml_4.readElement(HostXml_4.java:170) > at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:79) > at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:50) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) ... 4 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

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 June 2020