April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-724) Increase disk space available for PSI

by Kevin Earls (Jira)

Kevin Earls created SWSQE-724: --------------------------------- Summary: Increase disk space available for PSI Key: SWSQE-724 URL: https://issues.jboss.org/browse/SWSQE-724 Project: Kiali QE Issue Type: QE Task Reporter: Kevin Earls Currently we only have 2TB of disk allocated on PSI (See https://rhos-d.infra.prod.upshift.rdu2.redhat.com/dashboard/project/) We've already used 700g of this, even though we've used very few of our other resources. This is very likely to be a problem long term and should be increased. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3899) Submarine Jenkins fails the Quarkus REST test, using Quarkus >0.12

by Tibor Zimanyi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3899?page=com.atlassian.jira.plugi... ] Tibor Zimanyi edited comment on DROOLS-3899 at 4/25/19 8:06 AM: ---------------------------------------------------------------- It looks like that with my latest versioning changes related to poms from DROOLS-3900, this works now. [~tari_manga] could you please check and confirm? I used a Draft PR [1] to test it - it is based on your branch with some pom changes similar as changes in DROOLS-3900. [1] https://github.com/kiegroup/submarine-examples/pull/20 was (Author: tzimanyi): It looks like that with my latest versioning changes related to poms from https://issues.jboss.org/browse/DROOLS-3900, this works now. [~tari_manga] could you please check and confirm? I used a Draft PR [1] to test it - it is based on your branch with some pom changes similar as changes in DROOLS-3900. [1] https://github.com/kiegroup/submarine-examples/pull/20 > Submarine Jenkins fails the Quarkus REST test, using Quarkus >0.12 > ------------------------------------------------------------------ > > Key: DROOLS-3899 > URL: https://issues.jboss.org/browse/DROOLS-3899 > Project: Drools > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Matteo Mortari > Assignee: Tibor Zimanyi > Priority: Major > Labels: submarine > > -runtimes PR fails to run -example REST Quarkus test, when Quarkus version >0.12 > As demonstrated by history of Jenkins runs of this PR: > https://github.com/kiegroup/submarine-runtimes/pull/26 > which as part of CI will also run this: > https://github.com/kiegroup/submarine-examples/pull/15 > Error was: > [ERROR] testGET Time elapsed: 0.007 s <<< ERROR! > org.junit.jupiter.api.extension.TestInstantiationException: TestInstanceFactory [io.quarkus.test.junit.QuarkusTestExtension] failed to instantiate test class [org.kie.dmn.submarine.quarkus.example.ByNameDMNEndpointTest]: Failed to create the boostrap class loader > Caused by: java.lang.IllegalStateException: Failed to create the boostrap class loader > Caused by: io.quarkus.bootstrap.BootstrapException: Failed to locate current project among the loaded local projects > Please notice especially the last line. > I had the same problem locally with 0.13.1, but that was fixed locally with 0.13.3 > But trying with 0.13.3 keep failing on Jenkins CI when running -runtimes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3899) Submarine Jenkins fails the Quarkus REST test, using Quarkus >0.12

by Tibor Zimanyi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3899?page=com.atlassian.jira.plugi... ] Tibor Zimanyi commented on DROOLS-3899: --------------------------------------- It looks like that with my latest versioning changes related to poms from https://issues.jboss.org/browse/DROOLS-3900, this works now. [~tari_manga] could you please check and confirm? I used a Draft PR [1] to test it - it is based on your branch with some pom changes similar as changes in DROOLS-3900. [1] https://github.com/kiegroup/submarine-examples/pull/20 > Submarine Jenkins fails the Quarkus REST test, using Quarkus >0.12 > ------------------------------------------------------------------ > > Key: DROOLS-3899 > URL: https://issues.jboss.org/browse/DROOLS-3899 > Project: Drools > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Matteo Mortari > Assignee: Tibor Zimanyi > Priority: Major > Labels: submarine > > -runtimes PR fails to run -example REST Quarkus test, when Quarkus version >0.12 > As demonstrated by history of Jenkins runs of this PR: > https://github.com/kiegroup/submarine-runtimes/pull/26 > which as part of CI will also run this: > https://github.com/kiegroup/submarine-examples/pull/15 > Error was: > [ERROR] testGET Time elapsed: 0.007 s <<< ERROR! > org.junit.jupiter.api.extension.TestInstantiationException: TestInstanceFactory [io.quarkus.test.junit.QuarkusTestExtension] failed to instantiate test class [org.kie.dmn.submarine.quarkus.example.ByNameDMNEndpointTest]: Failed to create the boostrap class loader > Caused by: java.lang.IllegalStateException: Failed to create the boostrap class loader > Caused by: io.quarkus.bootstrap.BootstrapException: Failed to locate current project among the loaded local projects > Please notice especially the last line. > I had the same problem locally with 0.13.1, but that was fixed locally with 0.13.3 > But trying with 0.13.3 keep failing on Jenkins CI when running -runtimes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3900) Inheriting submarine-examples bom causes Quarkus Native Image integration tests to run anyway on normal JVM

by Tibor Zimanyi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3900?page=com.atlassian.jira.plugi... ] Tibor Zimanyi commented on DROOLS-3900: --------------------------------------- The Quarkus guidelines are general guidelines for using Maven failsafe plugin for running integration tests. This means that failsafe runs all tests matching "*IT.java" as integration tests. So to support both native and nonnative integration tests, I created Maven profiles with failsafe configuration [1] that for a nonnative run ignores native tests and for a native run, it runs all tests. With this, it was needed to include a naming convention for native tests. So for a test class to be run in a native run, it must match "Native*IT.java" or "Native*IntegrationTest.java" wildcards. It could be possible that with JUnit 5, JUnit will just ignore classes with @SubstrateTest annotation, but we will see when migrating to JUnit 5. I would expect the filtering be based on those annotations. [1] https://github.com/kiegroup/submarine-bom/blob/master/pom.xml#L902 > Inheriting submarine-examples bom causes Quarkus Native Image integration tests to run anyway on normal JVM > ----------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3900 > URL: https://issues.jboss.org/browse/DROOLS-3900 > Project: Drools > Issue Type: Bug > Affects Versions: 8.0.0.Final > Reporter: Matteo Mortari > Assignee: Tibor Zimanyi > Priority: Major > Labels: submarine > Fix For: 8.0.0.Final > > > Quarkus guidelines are for having Native image test in this form: > {code:java} > import io.quarkus.test.junit.SubstrateTest; > @SubstrateTest > public class NativeByNameDMNEndpointIT extends ByNameDMNEndpointTest { > // Execute the same tests but in native mode. > } > {code} > When the dmn example is inheriting from the submarine-examples bom, it causes those IT-ending tests to run anyway even on normal JVM. > See this commit exhibit the issue even locally: https://github.com/kiegroup/submarine-examples/pull/15/commits/1bdd53d89f... > Removing the pom inheritance, the test behavior is back Quarkus guideline -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster

by Joerg Baesner (Jira)

[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ] Joerg Baesner commented on WFLY-11833: -------------------------------------- [~rachmato] this is not a matter of having the reproducer running without indicating a failure on the command line. I did re-run the reproducer with the least recent commit on {{upstream/master}} as well. The result on the command line is absolutely intermittently (sometimes _success_, sometimes _failure_). Independent of the result of the command line execution we have to look into the resulting log in: {{ejb/build/reports/tests/test/classes/org.jboss.repro.stateful.timeout.StatefulTimeoutManagerTest.html}} In there we have the two log lines: {code} 2019.04.25 13:32:58 [Test worker] INFO o.j.r.s.t.StatefulTimeoutManagerTest - Manager strong affinity: Cluster "ejb", weak affinity: None ... 2019.04.25 13:32:59 [Test worker] INFO o.j.r.s.t.StatefulTimeoutManagerTest - Stateful strong affinity: URI<remote+http://127.0.0.1:9080>, weak affinity: URI<remote+http://127.0.0.1:9080> {code} In the reproducers test class {{StatefulTimeoutManagerTest}} we can see that the affinity of _Cluster "ejb"_ on *Manager strong affinity* is set hard coded in the test, whereas the affinity of _URI<remote+http://127.0.0.1:9080>_ on *Stateful strong affinity* is returned from the server and this is what is the actual issue here... > Stateful Session Bean affinity URI instead of cluster > ----------------------------------------------------- > > Key: WFLY-11833 > URL: https://issues.jboss.org/browse/WFLY-11833 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 16.0.0.Final > Environment: WildFly cluster having SFSB deployed. > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: stateful-timeout.zip > > > Deployed is an application with the following setup: > * Containing a SFSB (_with passivationCapable="true"_) > * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB > Scenario: > A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned. > The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster. > See the attached Gradle reproducer application -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-53) Upgrade WildFly Elytron to 1.9.0.CR4

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-53: -------------------------------------- Summary: Upgrade WildFly Elytron to 1.9.0.CR4 Key: ELYWEB-53 URL: https://issues.jboss.org/browse/ELYWEB-53 Project: Elytron Web Issue Type: Component Upgrade Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.4.1.CR1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1409) Update HTTP authentication mechanism API to support re-use of response handlers

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1409?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1409: ---------------------------------- Fix Version/s: 1.9.0.CR5 (was: 1.9.0.CR4) > Update HTTP authentication mechanism API to support re-use of response handlers > ------------------------------------------------------------------------------- > > Key: ELY-1409 > URL: https://issues.jboss.org/browse/ELY-1409 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.9.0.CR5 > > > At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request. > Making the scopes available should allow for state to be transferred on the request scope. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.9.0.CR5 (was: 1.9.0.CR4) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR5 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.9.0.CR5 (was: 1.9.0.CR4) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR5 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-243) Ensure reference to repository is removed from pom

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-243?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-243: --------------------------------- Fix Version/s: 1.9.0.CR5 (was: 1.9.0.CR4) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.jboss.org/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.9.0.CR5 > > > We need to ensure the reference to the JBoss repo is removed from the pom and artefacts are available from Maven Central. > Also at this point probably good to put the steps in place for Elytron to also be available from Maven Central. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019