August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4450) [DMN Designer] DMN Graph - Tooltips are not showing the text properly

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4450?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-4450: ------------------------------------ Attachment: (was: unnamed.png) > [DMN Designer] DMN Graph - Tooltips are not showing the text properly > --------------------------------------------------------------------- > > Key: DROOLS-4450 > URL: https://issues.jboss.org/browse/DROOLS-4450 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > > The tooltips are not showing the text properly in the DMN graph: -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by David White (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] David White edited comment on JGRP-2299 at 8/20/19 6:40 PM: ------------------------------------------------------------ I tried to test this fix (4.1.2) but unfortunately something seems to be broken with the CENTRAL_LOCK2 protocol. Upon shutdown, my application successfully closes the JChannel which uses the CENTRAL_LOCK2 protocol. However, after the application completely exits from all my application code the JVM is still running and never exits. It appears there is a thread still running the CENTRAL_LOCK2 protocol and it is stuck in the method processQueue() on the line "req=req_queue.take();}. The last version I tested was 4.0.19 so I don't know when this problem was introduced. Please advise. was (Author: dwhitejazz): I tried to test this fix (4.1.2) but unfortunately something seems to be broken with the CENTRAL_LOCK2 protocol. Upon shutdown, my application successfully closes the JChannel which uses the CENTRAL_LOCK2 protocol. However, after the application completely exits from all my application code the JVM is still running and never exits. It appears there is a thread still running the CENTRAL_LOCK2 protocol and it is stuck in the method processQueue() on the line "req=req_queue.take();}. The last version I tested was 4.0.19 so I don't know when this problem was introduced. Please advise. Dave From: "Bela Ban (Jira)" <issues(a)jboss.org> To: dfwhite(a)us.ibm.com Date: 08/02/2019 08:25 AM Subject: [EXTERNAL] [JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession Bela Ban resolved as Done Resolving this; let me know if this fixes all of your issues! JGroups / JGRP-2299 LockService does not work correctly if unlock/lock is called in immediate succession Change By: Bela Ban Status: Open Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.2 > > Attachments: JGroupsExample.java, image.png, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by David White (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] David White updated JGRP-2299: ------------------------------ Attachment: image.png I tried to test this fix (4.1.2) but unfortunately something seems to be broken with the CENTRAL_LOCK2 protocol. Upon shutdown, my application successfully closes the JChannel which uses the CENTRAL_LOCK2 protocol. However, after the application completely exits from all my application code the JVM is still running and never exits. It appears there is a thread still running the CENTRAL_LOCK2 protocol and it is stuck in the method processQueue() on the line "req=req_queue.take();}. The last version I tested was 4.0.19 so I don't know when this problem was introduced. Please advise. Dave From: "Bela Ban (Jira)" <issues(a)jboss.org> To: dfwhite(a)us.ibm.com Date: 08/02/2019 08:25 AM Subject: [EXTERNAL] [JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession Bela Ban resolved as Done Resolving this; let me know if this fixes all of your issues! JGroups / JGRP-2299 LockService does not work correctly if unlock/lock is called in immediate succession Change By: Bela Ban Status: Open Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.2 > > Attachments: JGroupsExample.java, image.png, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12398) Running testsuite/integration/microprofile-tck/opentracing twice without cleaning fails

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12398: --------------------------------------- Summary: Running testsuite/integration/microprofile-tck/opentracing twice without cleaning fails Key: WFLY-12398 URL: https://issues.jboss.org/browse/WFLY-12398 Project: WildFly Issue Type: Bug Components: MP OpenTracing Reporter: Brian Stansberry Assignee: Emmanuel Hugonnet If you try to run testsuite/integration/microprofile-tck/opentracing twice without cleaning you get: {code} [INFO] Running TestSuite [ERROR] Tests run: 46, Failures: 1, Errors: 0, Skipped: 45, Time elapsed: 4.175 s <<< FAILURE! - in TestSuite [ERROR] arquillianBeforeClass(org.eclipse.microprofile.opentracing.tck.OpentracingClientTests) Time elapsed: 3.661 s <<< FAILURE! org.jboss.shrinkwrap.api.exporter.FileExistsException: Target exists and we haven't been flagged to overwrite it: /Users/bstansberry/dev/wildfly/wildfly/testsuite/integration/microprofile-tck/opentracing/target/archives/testapp.war at org.jboss.shrinkwrap.impl.base.exporter.AbstractStreamExporterImpl.getOutputStreamToFile(AbstractStreamExporterImpl.java:87) at org.jboss.shrinkwrap.impl.base.exporter.AbstractStreamExporterImpl.exportTo(AbstractStreamExporterImpl.java:144) at org.jboss.shrinkwrap.impl.base.exporter.AbstractStreamExporterImpl.exportTo(AbstractStreamExporterImpl.java:167) at io.smallrye.opentracing.arquillian.DeploymentProcessor.process(DeploymentProcessor.java:75) at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.applyApplicationProcessors(DeploymentGenerator.java:223) at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.buildTestableDeployments(DeploymentGenerator.java:172) at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.createTestableDeployments(DeploymentGenerator.java:148) at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:85) {code} The io.smallrye.opentracing.arquillian.DeploymentProcessor class is in this maven module so perhaps the exportTo variant with an 'overwrite' field could be used. I have no idea if it's 'legal' in terms of TCK compliance to change those files though. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-4449: -------------------------------------- Story Points: (was: 5) > Visual design enhancements: Scenario/DMN error overlays > ------------------------------------------------------- > > Key: DROOLS-4449 > URL: https://issues.jboss.org/browse/DROOLS-4449 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor, Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Brian Dellascio > Priority: Major > Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools > > Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. > Verification conditions: > - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN) > - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-4449: -------------------------------------- Description: Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. Verification conditions: - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN) - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953. was: Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. Current DM context specific "design pattern" document: https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn... > Visual design enhancements: Scenario/DMN error overlays > ------------------------------------------------------- > > Key: DROOLS-4449 > URL: https://issues.jboss.org/browse/DROOLS-4449 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor, Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Brian Dellascio > Priority: Major > Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools > > Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. > Verification conditions: > - Review interaction design wireframes and click-thrus to offer recommendations for a consistent presentation for error overlays for the two editors (Scenario and DMN) > - Wireframes posted at: https://issues.jboss.org/browse/DROOLS-4257 and https://issues.jboss.org/browse/DROOLS-3953. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays

by Elizabeth Clayton (Jira)

Elizabeth Clayton created DROOLS-4449: ----------------------------------------- Summary: Visual design enhancements: Scenario/DMN error overlays Key: DROOLS-4449 URL: https://issues.jboss.org/browse/DROOLS-4449 Project: Drools Issue Type: Epic Components: DMN Editor, Scenario Simulation and Testing Reporter: Elizabeth Clayton Assignee: Margot Menestrot Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. Current DM context specific "design pattern" document: https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-4449: -------------------------------------- Issue Type: Enhancement (was: Epic) > Visual design enhancements: Scenario/DMN error overlays > ------------------------------------------------------- > > Key: DROOLS-4449 > URL: https://issues.jboss.org/browse/DROOLS-4449 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor, Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Margot Menestrot > Priority: Major > Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools > > Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. > Current DM context specific "design pattern" document: https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4449) Visual design enhancements: Scenario/DMN error overlays

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4449?page=com.atlassian.jira.plugi... ] Elizabeth Clayton reassigned DROOLS-4449: ----------------------------------------- Assignee: Brian Dellascio (was: Margot Menestrot) > Visual design enhancements: Scenario/DMN error overlays > ------------------------------------------------------- > > Key: DROOLS-4449 > URL: https://issues.jboss.org/browse/DROOLS-4449 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor, Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Brian Dellascio > Priority: Major > Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools > > Scenario and DMN editors share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) Support design consistency where applicable, while also documenting unique solutions per context. > Current DM context specific "design pattern" document: https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Nick Sawadsky edited comment on JGRP-2274 at 8/20/19 4:39 PM: -------------------------------------------------------------- [~belaban] I'm afraid not. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm. Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] has a good description of the steps. Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] describes how to go about implementing this type of encryption in Java. ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt. was (Author: nsawadsky): [~belaban] I'm afraid not. The decrypted message may be garbled, but it can still decrypt successfully, depending on the encryption algorithm. Adding an additional INTEGRITY protocol is one possible option. Using an HMAC is preferred these days over a checksum. HMAC needs its own shared key, so this may be one reason to keep the signing as part of the encryption protocol (so it can reuse the same shared secret). It seems the best practice would be to derive two different keys (one for encryption and one for signing) from the same shared secret using a key derivation function. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] has a good description of the steps: Implementing HMAC is a bit complicated, which would be a reason to instead add support for GCM mode in Encrypt. This will require some changes as well I think, but the work would be quite a bit less. I think "mode" and "padding" would have to be added as configuration properties for the base Encrypt class. GCM also needs a unique initialization vector for each encrypted message. So Encrypt would need to be able to generate an initialization vector (with configurable length) per encrypted message. [This article|https://proandroiddev.com/security-best-practices-symmetric-encry...] describes how to go about implementing this type of encryption in Java. ECB is seen as a somewhat less secure choice of mode these days anyway, so even if HMAC support were added, it still would be advisable to also add support for alternate encryption modes in Encrypt. > ASYM_ENCRYPT: deprecate sign_msgs > --------------------------------- > > Key: JGRP-2274 > URL: https://issues.jboss.org/browse/JGRP-2274 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.12 > > > In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature. > However, this is redundant, as decryption of a message will fail if the contents have been changed. > If needed, signing of messages can be done in a separate protocol. -- 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