August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-930) Backup Jenkins Install-Maistra Failure: Failed to prepare archiveArtifacts

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-930: ------------------------------------- Summary: Backup Jenkins Install-Maistra Failure: Failed to prepare archiveArtifacts Key: SWSQE-930 URL: https://issues.jboss.org/browse/SWSQE-930 Project: Kiali QE Issue Type: Task Reporter: Matthew Mahoney Assignee: Filip Brychta Job console: http://10.0.148.41:8080/job/install-maistra/471/console [Pipeline] archiveArtifacts Error when executing always post condition: java.lang.IllegalArgumentException: Failed to prepare archiveArtifacts step at org.jenkinsci.plugins.workflow.cps.DSL.invokeDescribable(DSL.java:419) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:182) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScrip -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12374) Transactions store attributes have wrong configuration

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12374?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12374: ----------------------------------------- [~michpetrov] Probably but then you'd have the 3 (now deprecated) boolean flags and the enum, at least until we got to a release where the boolean attributes could be dropped without breaking compatibility rules. And you'd have to do transformation for mixed domain. So not a bad idea but not trivial. > Transactions store attributes have wrong configuration > ------------------------------------------------------ > > Key: WFLY-12374 > URL: https://issues.jboss.org/browse/WFLY-12374 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 17.0.1.Final > Reporter: Michal Petrov > Assignee: Michal Petrov > Priority: Minor > > Transactions subsystem has these attributes: > * use-hornetq-store > * use-journal-store > * use-jdbc store > each of those has the other two set up as alternatives, however "journal" is an alias of "hornetq" and so those two shouldn't be treated as mutually exclusive. > (As far as I know this doesn't break anything because of the way the attributes are handled, but it poses a problem for WFCORE-4287) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-926) Fix test_service_detail_with_destination_rule e2e test

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-926?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-926. --------------------------------- Resolution: Done > Fix test_service_detail_with_destination_rule e2e test > ------------------------------------------------------ > > Key: SWSQE-926 > URL: https://issues.jboss.org/browse/SWSQE-926 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: automation > > The test is failing with Exception: Timed out waiting for destination rule deletion -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-929) Molecule maistra-e2e Not Running On AWS

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-929: ------------------------------------- Summary: Molecule maistra-e2e Not Running On AWS Key: SWSQE-929 URL: https://issues.jboss.org/browse/SWSQE-929 Project: Kiali QE Issue Type: Task Reporter: Matthew Mahoney Assignee: Guilherme Baufaker Rêgo Need to be able to run Molecule tests on AWS, but currently tests fail because access quay.io/maistra/kiali-operator is not authorized Ex: Failed to pull image "quay.io/maistra/kiali-operator:1.0.5": rpc error: code = Unknown desc = Error reading manifest 1.0.5 in quay.io/maistra/kiali-operator: unauthorized: access to the requested resource is not authorized Note: The Secret is present and the following lines are not commented secret_file_path: "{{ lookup('env', 'MOLECULE_PROJECT_DIRECTORY') }}/molecule/maistra-e2e/assets/secret.yaml" secret: "{{ lookup('template', secret_file_path) | from_yaml }}" -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4436) Increase color contrast in process instance details SVG badges

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-4436: ----------------------------------------- Summary: Increase color contrast in process instance details SVG badges Key: DROOLS-4436 URL: https://issues.jboss.org/browse/DROOLS-4436 Project: Drools Issue Type: Bug Components: Stunner Reporter: Elizabeth Clayton Assignee: Mario Fusco Attachments: Screen Shot 2019-08-14 at 1.24.03 PM.png, Screen Shot 2019-08-14 at 1.30.43 PM.png The badges are light gray with white text which will most likely not be easily legible and possibly not accessible. It appears that they do follow the PF styles, although these have since been updated. Usability will be improved if the badges are updated to the current styles, as documented at: https://pf4.patternfly.org/components/Badge/examples/. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1771) Serialization is triggering rule multiple times

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-1771?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1771: -------------------------------- Sprint: 2019 Week 35-37 (was: 2019 Week 32-34) > Serialization is triggering rule multiple times > ------------------------------------------------ > > Key: DROOLS-1771 > URL: https://issues.jboss.org/browse/DROOLS-1771 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final, 7.3.0.Final > Reporter: Christopher Brecht > Assignee: Mario Fusco > Priority: Major > Attachments: EventA.java, Person.java, Reproducer.java > > > I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization. > The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events. > +*WITH SERIALIZATION *+ > STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] > STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010] > STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] > STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] > STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] > +*WITHOUT SERIALIZATION *+ > STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010] > STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010] > STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBEE-208) Update GAV for next JACC Release

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/JBEE-208?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated JBEE-208: ---------------------------------- Description: Current pom of Java EE fork: - {noformat} <groupId>org.jboss.spec.javax.security.jacc</groupId> <artifactId>jboss-jacc-api_1.5_spec</artifactId> <version>1.0.3.Final-SNAPSHOT</version> {noformat} So will match but set version to 2.0.0.CR1-SNAPSHOT > Update GAV for next JACC Release > -------------------------------- > > Key: JBEE-208 > URL: https://issues.jboss.org/browse/JBEE-208 > Project: JBoss Enterprise Spec APIs > Issue Type: Task > Components: jboss-jacc-api > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > > Current pom of Java EE fork: - > {noformat} > <groupId>org.jboss.spec.javax.security.jacc</groupId> > <artifactId>jboss-jacc-api_1.5_spec</artifactId> > <version>1.0.3.Final-SNAPSHOT</version> > {noformat} > So will match but set version to 2.0.0.CR1-SNAPSHOT -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBEE-208) Update GAV for next JACC Release

by Darran Lofthouse (Jira)

Darran Lofthouse created JBEE-208: ------------------------------------- Summary: Update GAV for next JACC Release Key: JBEE-208 URL: https://issues.jboss.org/browse/JBEE-208 Project: JBoss Enterprise Spec APIs Issue Type: Task Components: jboss-jacc-api Reporter: Darran Lofthouse Assignee: Darran Lofthouse -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4607) DeploymentReplaceHandler is doing an unnecessary recursive read of the entire management model

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4607: ---------------------------------------- Summary: DeploymentReplaceHandler is doing an unnecessary recursive read of the entire management model Key: WFCORE-4607 URL: https://issues.jboss.org/browse/WFCORE-4607 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Brian Stansberry Assignee: Brian Stansberry DeploymentReplaceHandler recursively reads the root model node just to check if it has a couple direct children. A non-recursive read can provide that information without requiring a clone of the model. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4603) Replace Deployment --runtime-name option not working

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-4603?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-4603 at 8/14/19 12:12 PM: -------------------------------------------------------------------- [~ehugonnet] [~yersan] -A tangent to clean up as part of any work on this: https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... That should be context.readResource(PathAddress.EMPTY_ADDRESS, false); as we don't want to read the entire model just to check for child names.- Never mind; I missed that there was already a PR for this. was (Author: brian.stansberry): [~ehugonnet] [~yersan] A tangent to clean up as part of any work on this: https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... That should be context.readResource(PathAddress.EMPTY_ADDRESS, false); as we don't want to read the entire model just to check for child names. > Replace Deployment --runtime-name option not working > ---------------------------------------------------- > > Key: WFCORE-4603 > URL: https://issues.jboss.org/browse/WFCORE-4603 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 10.0.0.Beta4 > Environment: Red Hat JBoss Enterprise Application Platform (EAP) 7.2 CP 3. > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > > The scenario is that, if you have a deployment to be switched by a new one, the runtime-name property doesn't work the way it should. See the sequence of the commands bellow: > [standalone@localhost:9990 /] deploy helloworld-rs.war > [standalone@localhost:9990 /] deploy helloworld-rs-second.war —disabled > [standalone@localhost:9990 /] :replace-deployment(name=helloworld-rs-second.war,to-replace=helloworld-rs.war,runtime-name=foo.war) > [standalone@localhost:9990 /] /deployment=helloworld-rs-second.war:read-resource > { > "outcome" => "success", > "result" => { > "content" => [{"hash" => bytes { > 0xfe, 0x24, 0x1f, 0xd3, 0x19, 0xa3, 0x72, 0xd4, > 0xc6, 0xa4, 0x48, 0xe7, 0x8b, 0x9c, 0xc1, 0xd4, > 0xc7, 0x17, 0xdf, 0xaa > }}], > "enabled" => false, > "name" => "helloworld-rs-second.war", > "owner" => undefined, > "persistent" => true, > "runtime-name" => "helloworld-rs-second.war", > "subdeployment" => undefined, > "subsystem" => { > "undertow" => undefined, > "ejb3" => undefined, > "logging" => undefined > } > } > } > Foo.war is not applied. Looks like it was ignored. -- 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 August 2019