March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12834) CVE-2019-14887 The 'enabled-protocols' value in legacy security is not respected if OpenSSL security provider is in use

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-12834?page=com.atlassian.jira.plugi... ] Farah Juma updated WFLY-12834: ------------------------------ Security: (was: Security Issue) > CVE-2019-14887 The 'enabled-protocols' value in legacy security is not respected if OpenSSL security provider is in use > ----------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12834 > URL: https://issues.redhat.com/browse/WFLY-12834 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Kunjan Rathod > Assignee: Farah Juma > Priority: Major > Fix For: 20.0.0.Beta1 > > > Security Issue > Do not make this issue public. > The 'enabled-protocols' attribute in legacy security seems not to be working if 'openssl.TLS' provider is in use. If regular JSSE provider with 'TLS' value is in use, it is working just fine, although not in case 'openssl.TLS'. See more info in reproduction steps. > NOTE as described in WFCORE-4737 comment, this is a possible security issue as an attacker can simply persuade server to communicate with him via lower TLS version than which is specified in server configuration! This is currently also a reason why this is marked as blocker now. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5056) [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned

by Daniel José dos Santos (Jira)

[ https://issues.redhat.com/browse/DROOLS-5056?page=com.atlassian.jira.plug... ] Daniel José dos Santos commented on DROOLS-5056: ------------------------------------------------ No problem. If it's only reproducible here I guess it can be something with my specific setup. I'll try to investigate it further in the future to see if I can reproduce this again. Thank you all! > [DMN Designer] Sometimes the nodes inside Decision Service are wrong positioned > ------------------------------------------------------------------------------- > > Key: DROOLS-5056 > URL: https://issues.redhat.com/browse/DROOLS-5056 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Daniel José dos Santos > Assignee: Michael Anstis > Priority: Minor > Labels: drools-tools > Attachments: issue.mp4, taxRate.dmn > > > Sometimes the nodes inside the Decision Service are positioned outside from the Decision Service when the .DMN is saved an open again. > I was unable to map exact when this happen, but I noticed that this happens depending on the changes you do in the position and size of the Decision Service and its inner nodes. > I recorded a video with 2 minutes when the issue happens in the last seconds. > As it can be notice it takes lots of trials to reproduce the issue. > Also I was unable to reproduce the issue in the Business Central, so I'm not sure if it is related to DMN Editor in VS Code or DMN Editor itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13223) Upgrade HAL to 3.2.8.Final

by Harald Pehl (Jira)

[ https://issues.redhat.com/browse/WFLY-13223?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFLY-13223: ------------------------------- Fix Version/s: 20.0.0.Beta1 > Upgrade HAL to 3.2.8.Final > -------------------------- > > Key: WFLY-13223 > URL: https://issues.redhat.com/browse/WFLY-13223 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Bartosz Spyrko > Assignee: Harald Pehl > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13297) Weld @Resource injection does not handle expressions in the annotation attributes

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13297?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13297: ------------------------------------ Description: WFLY-1995 added support for expression resolution in the values of some attributes of some annotations, including @Resource. But thus isn't applied to all handling of @Resource. ResourceInjectionAnnotationParsingProcessor handles, which AFAICT means it's handled for EJBs (and perhaps other EE components) but it isn't handled in a simple CDI bean. You get a failure like this: {code} Caused by: javax.naming.NameNotFoundException: ${the.expression} -- service jboss.naming.context.java."${the.expression}" at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) at javax.naming.InitialContext.lookup(InitialContext.java:417) at javax.naming.InitialContext.lookup(InitialContext.java:417) at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:236) ... 73 more {code} The PropertyReplacer obtained from the DeploymentUnit that is used by ResourceInjectionAnnotationParsingProcessor is also available to the weld subsystem code that creates WeldResourceInjectionServices so a possible fix is to pass it in and have WeldResourceInjectionServices use it. Manual testing shows that allows an app with such a bean to work. was: WFLY-1995 added support for expression resolution in the values of some attributes of some annotations, including @Resource. But thus isn't applied to all handling of @Resource. ResourceInjectionAnnotationParsingProcessor handles, which AFAICT means it's handled for EJBs (and perhaps other EE components) but it isn't handled in a simple CDI bean. You get a failure like this: {code} Caused by: javax.naming.NameNotFoundException: ${the.expression} -- service jboss.naming.context.java."${some.defined.property}" at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) at javax.naming.InitialContext.lookup(InitialContext.java:417) at javax.naming.InitialContext.lookup(InitialContext.java:417) at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:236) ... 73 more {code} The PropertyReplacer obtained from the DeploymentUnit that is used by ResourceInjectionAnnotationParsingProcessor is also available to the weld subsystem code that creates WeldResourceInjectionServices so a possible fix is to pass it in and have WeldResourceInjectionServices use it. Manual testing shows that allows an app with such a bean to work. > Weld @Resource injection does not handle expressions in the annotation attributes > --------------------------------------------------------------------------------- > > Key: WFLY-13297 > URL: https://issues.redhat.com/browse/WFLY-13297 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EE > Affects Versions: 19.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Beta1 > > > WFLY-1995 added support for expression resolution in the values of some attributes of some annotations, including @Resource. But thus isn't applied to all handling of @Resource. ResourceInjectionAnnotationParsingProcessor handles, which AFAICT means it's handled for EJBs (and perhaps other EE components) but it isn't handled in a simple CDI bean. > You get a failure like this: > {code} > Caused by: javax.naming.NameNotFoundException: ${the.expression} -- service jboss.naming.context.java."${the.expression}" > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:236) > ... 73 more > {code} > The PropertyReplacer obtained from the DeploymentUnit that is used by ResourceInjectionAnnotationParsingProcessor is also available to the weld subsystem code that creates WeldResourceInjectionServices so a possible fix is to pass it in and have WeldResourceInjectionServices use it. Manual testing shows that allows an app with such a bean to work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13295) REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/WFLY-13295?page=com.atlassian.jira.plugi... ] Michael Musgrove commented on WFLY-13295: ----------------------------------------- I looked at the comment on the narayana pr/1573, does that comment imply that the PR for this WFLY issue will include a test after the Narayana component upgrade? > REST-AT inbound bridge is not activated for EJB without TransactionalManagement annotation > ------------------------------------------------------------------------------------------ > > Key: WFLY-13295 > URL: https://issues.redhat.com/browse/WFLY-13295 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 19.0.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The REST-AT inbound bridge is activated per deployment. It's activated for a deployment which contains a REST endpoint identified with `@Path` annotation where in the same class has to be included either annotation `@Transactional` or `@TransactionAttribute`. > The point is to activate the inbound bridge for deployments which contain a transactional managed method (CDI or EJB) which can receive the txn context, ie. possibly a context of REST-AT transaction as well. > The issue is that EJB beans are transactional by default. The EJB bean class does not need to specify any `@TransactionalAttribute` to be already container managed (from txn perspective) with attribute `REQUIRED`. Which means taking incoming txn context and will work with it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-4005) [DMN Designer] Improve the Data Types support (7.5)

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4005?page=com.atlassian.jira.plug... ] Guilherme Gomes resolved DROOLS-4005. ------------------------------------- Resolution: Done > [DMN Designer] Improve the Data Types support (7.5) > --------------------------------------------------- > > Key: DROOLS-4005 > URL: https://issues.redhat.com/browse/DROOLS-4005 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: UX, UXTeam, drools-tools > > This is an umbrella for all JIRAs (target to 7.5) related to enhancements on Data Types. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5201) ZipException is thrown when guided asset is opened

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5201?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5201: -------------------------------- Tester: Jozef Marko > ZipException is thrown when guided asset is opened > -------------------------------------------------- > > Key: DROOLS-5201 > URL: https://issues.redhat.com/browse/DROOLS-5201 > Project: Drools > Issue Type: Bug > Components: Guided Template Editor > Affects Versions: 7.36.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Blocker > Labels: drools-tools > Attachments: Screenshot from 2020-03-27 15-30-54.png, error.log > > > User is unable to work with guided editors. Always guided editor is opened, this exception is thrown. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5201) ZipException is thrown when guided asset is opened

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5201: ----------------------------------- Summary: ZipException is thrown when guided asset is opened Key: DROOLS-5201 URL: https://issues.redhat.com/browse/DROOLS-5201 Project: Drools Issue Type: Bug Components: Guided Template Editor Affects Versions: 7.36.0.Final Reporter: Jozef Marko Assignee: Michael Anstis Attachments: Screenshot from 2020-03-27 15-30-54.png, error.log User is unable to work with guided editors. Always guided editor is opened, this exception is thrown. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2462) TransferQueueBundler: drop messages if queue is full

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2462?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2462: -------------------------------- Initial implementation of {{RED}} is done. Next: unit test reproducing the issue and showing that the fix works... > TransferQueueBundler: drop messages if queue is full > ---------------------------------------------------- > > Key: JGRP-2462 > URL: https://issues.redhat.com/browse/JGRP-2462 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.2, 5.0.0.Alpha4 > > > When a bundler (like {{TransferQueueBundler}}) has a full queue, the senders will block. > This can happen for example when the TCP {{send}} blocks due to a full send-window. > Retransmission requests and responses compound the problem when the TQB's queue is full. > Therefore, in addition to blocking, we should add an option to _drop_ packets when the queue is full. Investigate whether we could use some priority based scheme, which drops non-important messages first. > Also investigate whether senders can selectively be unblocked when the queue is full, to either drop or add their messages. This could be done for example by removing elements from the queue, using the aformentioned filter. > Look at random early detection )\[1\]) for inspiration. > \[1\] https://en.wikipedia.org/wiki/Random_early_detection -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-5200) Enumeration types are "dirty" when opened (without making changes)

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5200?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-5200: ----------------------------------- Labels: drools-tools (was: ) > Enumeration types are "dirty" when opened (without making changes) > ------------------------------------------------------------------ > > Key: DROOLS-5200 > URL: https://issues.redhat.com/browse/DROOLS-5200 > Project: Drools > Issue Type: Bug > Components: Enumerations Editor > Affects Versions: 7.35.0.Final > Reporter: Tihomir Surdilovic > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: Screen Shot 2020-03-26 at 10.29.31 PM.png > > > Open existing enumeration type in BC > Close it > Popup shows asking if you want to save changes -- 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 March 2020