May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-576) run-python3-ui-tests job sometimes stuck

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-576?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-576: ------------------------------------- This still happens from time to time. > run-python3-ui-tests job sometimes stuck > ---------------------------------------- > > Key: SWSQE-576 > URL: https://issues.jboss.org/browse/SWSQE-576 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > Labels: automation > > run-python3-ui-tests is sometimes stuck after the tests finish. The pytest process is still running on the jenkins slave. Probably there is some connection which is not closed - maybe to zalenium? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-725) Optimize test_services_page.test_service_details_random

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-725?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan resolved SWSQE-725. ---------------------------------- Resolution: Done > Optimize test_services_page.test_service_details_random > ------------------------------------------------------- > > Key: SWSQE-725 > URL: https://issues.jboss.org/browse/SWSQE-725 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > It started taking 7 mins to execute. > Should be investigated and optimized in a scope of 3 minutes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools

by Fabio Bonfante (Jira)

[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ] Fabio Bonfante edited comment on DROOLS-1540 at 5/13/19 5:43 AM: ----------------------------------------------------------------- I add just two cents on the "issue" sharing my experience on another corner-case... (sadly) Java serialization. I was able to use the documented work-around, I've a spring-devtools.properties with: {{restart.include.drools-core=/drools-core-7.0.0.Final.jar restart.include.drools-compiler=/drools-compiler-7.0.0.Final.jar restart.include.kie-api=/kie-api-7.0.0.Final.jar restart.include.kie-ci=/kie-ci-7.0.0.Final.jar restart.include.kie-internal=/kie-internal-7.0.0.Final.jar }} But in a rule using java serialization, I got an amazing: {{Caused by: java.lang.ClassCastException: com.example.OrderREO cannot be cast to com.example.OrderREO at rules.com.example.CloneWithServiceCode.cloneWithServiceCode(CloneWithServiceCode.java:55) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706.defaultConsequence(My_Rule_621849765706.java:9) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na] at org.drools.core.phreak.RuleExecutor.innerFireActivation(RuleExecutor.java:431) ~[drools-core-7.0.0.Final.jar:7.0.0.Final] ... 129 common frames omitted}} Given that I'll have to wipe-out every form of Java Serialization from the rules... (the Object.clone() was so tempting for our business-rules team... and they didn't knows the drawbacks) I would like to know if I missed to specify some jar in the spring-devtools.properties. Thank's in advance. was (Author: fabio.bonfante): I add just two cents on the "issue" sharing my experience on another corner-case... (sadly) Java serialization. I was able to use the documented work-around, I've a spring-devtools.properties with: {{ restart.include.drools-core=/drools-core-7.0.0.Final.jar restart.include.drools-compiler=/drools-compiler-7.0.0.Final.jar restart.include.kie-api=/kie-api-7.0.0.Final.jar restart.include.kie-ci=/kie-ci-7.0.0.Final.jar restart.include.kie-internal=/kie-internal-7.0.0.Final.jar }} But in a rule using java serialization, I got an amazing: {{Caused by: java.lang.ClassCastException: com.example.OrderREO cannot be cast to com.example.OrderREO at rules.com.example.CloneWithServiceCode.cloneWithServiceCode(CloneWithServiceCode.java:55) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706.defaultConsequence(My_Rule_621849765706.java:9) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na] at org.drools.core.phreak.RuleExecutor.innerFireActivation(RuleExecutor.java:431) ~[drools-core-7.0.0.Final.jar:7.0.0.Final] ... 129 common frames omitted}} Given that I'll have to wipe-out every form of Java Serialization from the rules... (the Object.clone() was so tempting for our business-rules team... and they didn't knows the drawbacks) I would like to know if I missed to specify some jar in the spring-devtools.properties. Thank's in advance. > Drools does not work with spring-boot-devtools > ---------------------------------------------- > > Key: DROOLS-1540 > URL: https://issues.jboss.org/browse/DROOLS-1540 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final, 7.20.0.Final > Reporter: G Xiong > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.zip > > > Drools does work with spring-boot-devtools. > If you add in pom.xml the following, no rules will be fired in Drools. > <dependency> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-devtools</artifactId> > </dependency> > if you comment out this, then rules will be fired in Drools. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools

by Fabio Bonfante (Jira)

[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ] Fabio Bonfante commented on DROOLS-1540: ---------------------------------------- I add just two cents on the "issue" sharing my experience on another corner-case... (sadly) Java serialization. I was able to use the documented work-around, I've a spring-devtools.properties with: {{ restart.include.drools-core=/drools-core-7.0.0.Final.jar restart.include.drools-compiler=/drools-compiler-7.0.0.Final.jar restart.include.kie-api=/kie-api-7.0.0.Final.jar restart.include.kie-ci=/kie-ci-7.0.0.Final.jar restart.include.kie-internal=/kie-internal-7.0.0.Final.jar }} But in a rule using java serialization, I got an amazing: {{Caused by: java.lang.ClassCastException: com.example.OrderREO cannot be cast to com.example.OrderREO at rules.com.example.CloneWithServiceCode.cloneWithServiceCode(CloneWithServiceCode.java:55) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706.defaultConsequence(My_Rule_621849765706.java:9) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na] at rules.com.example.Rule_My_Rule_621849765706DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na] at org.drools.core.phreak.RuleExecutor.innerFireActivation(RuleExecutor.java:431) ~[drools-core-7.0.0.Final.jar:7.0.0.Final] ... 129 common frames omitted}} Given that I'll have to wipe-out every form of Java Serialization from the rules... (the Object.clone() was so tempting for our business-rules team... and they didn't knows the drawbacks) I would like to know if I missed to specify some jar in the spring-devtools.properties. Thank's in advance. > Drools does not work with spring-boot-devtools > ---------------------------------------------- > > Key: DROOLS-1540 > URL: https://issues.jboss.org/browse/DROOLS-1540 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final, 7.20.0.Final > Reporter: G Xiong > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.zip > > > Drools does work with spring-boot-devtools. > If you add in pom.xml the following, no rules will be fired in Drools. > <dependency> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-devtools</artifactId> > </dependency> > if you comment out this, then rules will be fired in Drools. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11828) Bump messaging schema version to 7.0

by Emmanuel Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-11828?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet commented on WFLY-11828: ------------------------------------------ Adding also a fix for pull request #11918 from TomasHofman/WFLY-11404 which should have been on version7.0 of the schema and not 6.0 (thus the blocker status) > Bump messaging schema version to 7.0 > ------------------------------------ > > Key: WFLY-11828 > URL: https://issues.jboss.org/browse/WFLY-11828 > Project: WildFly > Issue Type: Task > Components: JMS > Affects Versions: 16.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Blocker > Labels: EAP-CD17 > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11828) Bump messaging schema version to 7.0

by Emmanuel Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-11828?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFLY-11828: ------------------------------------- Labels: EAP-CD17 (was: ) > Bump messaging schema version to 7.0 > ------------------------------------ > > Key: WFLY-11828 > URL: https://issues.jboss.org/browse/WFLY-11828 > Project: WildFly > Issue Type: Task > Components: JMS > Affects Versions: 16.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Blocker > Labels: EAP-CD17 > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11828) Bump messaging schema version to 7.0

by Emmanuel Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-11828?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFLY-11828: ------------------------------------- Priority: Blocker (was: Major) > Bump messaging schema version to 7.0 > ------------------------------------ > > Key: WFLY-11828 > URL: https://issues.jboss.org/browse/WFLY-11828 > Project: WildFly > Issue Type: Task > Components: JMS > Affects Versions: 16.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Blocker > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFCORE-629: ------------------------------- Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta6) > Enabled automatic encryption of passwords stored in configuration > ----------------------------------------------------------------- > > Key: WFCORE-629 > URL: https://issues.jboss.org/browse/WFCORE-629 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Environment: Wildfly 9 > Reporter: Jason Shepherd > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.CR1 > > > Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration. > It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4172) Add support for TLS 1.3

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4172?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4172: -------------------------------- Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta6) > Add support for TLS 1.3 > ----------------------- > > Key: WFCORE-4172 > URL: https://issues.jboss.org/browse/WFCORE-4172 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Labels: eap-7.2.0-deferred > Fix For: 9.0.0.CR1 > > > It presently appears as though TLS 1.3 support could be available from Java 11. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4150) Support automatically adding / updating credentials in the CredentialStore

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4150?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4150: -------------------------------- Fix Version/s: 9.0.0.CR1 (was: 9.0.0.Beta6) > Support automatically adding / updating credentials in the CredentialStore > -------------------------------------------------------------------------- > > Key: WFCORE-4150 > URL: https://issues.jboss.org/browse/WFCORE-4150 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 May 2019