January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13009?page=com.atlassian.jira.plugi... ] Richard Achmatowicz reassigned WFLY-13009: ------------------------------------------ Assignee: Richard Achmatowicz (was: Paul Ferraro) > moduleAvailability message is sent before module has started > ------------------------------------------------------------ > > Key: WFLY-13009 > URL: https://issues.redhat.com/browse/WFLY-13009 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 19.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > > When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node. > The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping). > It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13009) moduleAvailability message is sent before module has started

by Richard Achmatowicz (Jira)

Richard Achmatowicz created WFLY-13009: ------------------------------------------ Summary: moduleAvailability message is sent before module has started Key: WFLY-13009 URL: https://issues.redhat.com/browse/WFLY-13009 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 19.0.0.Beta1 Reporter: Richard Achmatowicz Assignee: Paul Ferraro When EJBs are deployed in a clustered server environment, moduleAvailability messages are sent from the server to all connected EJB client applications in order to inform the client that the module is available on that node. The sending of moduleAvailability messages involves the DeploymentRepository, which records which modules are deployed, and the ModuleAvailabilityListener, which is a DeploymentRepositoryListener which gets called at various stages of module deployment (adding, starting, stopping). It looks as though moduleAvailability message are being sent earlier than they should be; in other words, sent when the module is added to the repository and not when the module is later started. This can cause client invocations on the module to return a NoSuchEJBException even after the moduleAvailability message has been sent to the client, causing what is seen in EJBCLIENT-362. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4810) Upgrade WildFly Elytron to 1.11.1.Final

by Farah Juma (Jira)

Farah Juma created WFCORE-4810: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.11.1.Final Key: WFCORE-4810 URL: https://issues.redhat.com/browse/WFCORE-4810 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1921) [GSS][7.2.2] HTTP External Security Not Supported by Elytron

by Ashley Abdel-Sayed (Jira)

[ https://issues.redhat.com/browse/ELY-1921?page=com.atlassian.jira.plugin.... ] Ashley Abdel-Sayed updated ELY-1921: ------------------------------------ Issue Type: Feature Request (was: Requirement) > [GSS][7.2.2] HTTP External Security Not Supported by Elytron > ------------------------------------------------------------ > > Key: ELY-1921 > URL: https://issues.redhat.com/browse/ELY-1921 > Project: WildFly Elytron > Issue Type: Feature Request > Affects Versions: 1.11.0.Final > Reporter: Ashley Abdel-Sayed > Assignee: Ashley Abdel-Sayed > Priority: Major > > For legacy security, there's an EXTERNAL HTTP authentication mechanism (io.undertow.security.impl.ExternalAuthenticationMechanism) which performs no verification and simply uses the principal that was passed from the REMOTE_USER attribute by the AJP protocol. There is a "ClientLoginModule" in legacy security used as such: https://access.redhat.com/solutions/3465231. It is a requirement to add an equivalent of this EXTERNAL mechanism available in legacy and Elytron-SASL for Elytron-HTTP in order to migrate away from legacy security. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13003) Support the SameSite cookie attribute

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/WFLY-13003?page=com.atlassian.jira.plugi... ] Masafumi Miura edited comment on WFLY-13003 at 1/23/20 10:32 AM: ----------------------------------------------------------------- I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies or the cookie which matches the specified name - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute. The regex is based on https://www.chromium.org/updates/same-site/incompatible-clients The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>       </filters> </subsystem> {code} was (Author: mmiura): I've already raised UNDERTOW-1600 which is related to this feature. I've just updated a PR for UNDERTOW-1600 https://github.com/undertow-io/undertow/pull/816 which contains the following changes: - Add support for the SameSite=None attribute - Add SameSiteCookieHandler that can set the SameSite attribute on all cookies - Add a utility class SameSiteNoneIncompatibleClientChecker to detect user agents which are incompatible with the SameSite=None attribute. The regex is based on https://www.chromium.org/updates/same-site/incompatible-clients The SameSiteCookieHandler can be enabled with the predicate name "samesite-cookie" through expression-filter in the undertow subsystem. For example: {code:xml} <subsystem xmlns="urn:jboss:domain:undertow:7.0" ...> ... <server name="default-server"> ... <host name="default-host" alias="localhost"> <location name="/" handler="welcome-content"/> <http-invoker security-realm="ApplicationRealm"/>  <filter-ref name="samesite-cookie"/>  </host> </server> ...(snip)... <filters>  <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=strict)"/>    <expression-filter name="samesite-cookie" expression="samesite-cookie(mode=none)"/> </filters> </subsystem> {code} > Support the SameSite cookie attribute > ------------------------------------- > > Key: WFLY-13003 > URL: https://issues.redhat.com/browse/WFLY-13003 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Flavia Rainone > Priority: Major > > Chrome 80 is going to significantly change how cookies are handled, as per this notice at [1], with a bit of an explanation of what the same site attribute means at [2]. > At the moment the Servlet specification has no way of setting this particular attribute, and it is not possible to configure it via container specific configuration in WildFly at present (it can only be done by writing some Undertow specific code). > I propose we add a same-site-cookie-attribute predicated handler to undertow, which takes an optional cookie name regex, and the value for the attribute to set. > This would allow users to configure the SameSite attribute based on cookie name, and also potentially based on any other attributes including user agent, as it sounds like some browsers may have bugs that means this might need to be set on a per user agent basis. > [1] https://www.chromestatus.com/feature/5088147346030592 > [2] https://web.dev/samesite-cookies-explained/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4961) User / Role Permissions on package level

by Alexandre Bakos (Jira)

[ https://issues.redhat.com/browse/DROOLS-4961?page=com.atlassian.jira.plug... ] Alexandre Bakos edited comment on DROOLS-4961 at 1/23/20 10:29 AM: ------------------------------------------------------------------- I see your point, although this is an organizational issue as the technical best practice would be split the project anyway, think about monolith vs. MSA. And, as I pointed in my previous comment, even if we could consider this... the results would be flawed as Git doesn't provide such a feature. > User / Role Permissions on package level > ---------------------------------------- > > Key: DROOLS-4961 > URL: https://issues.redhat.com/browse/DROOLS-4961 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.31.0.Final > Reporter: Nikos Tsekouras > Assignee: David Gutierrez > Priority: Major > Labels: drools-tools > > It will be amazingly helpful to have the ability to minimize the access / permissions of a user / group on package level. > Within a project you can define several packages - for different purposes - and you need each team to be able to work on / view a specific package. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1925) Release WildFly Elytron 1.11.1.Final

by Farah Juma (Jira)

Farah Juma created ELY-1925: ------------------------------- Summary: Release WildFly Elytron 1.11.1.Final Key: ELY-1925 URL: https://issues.redhat.com/browse/ELY-1925 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.11.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4919) Long running query at kie-server startup

by Jonathan Fisher (Jira)

[ https://issues.redhat.com/browse/DROOLS-4919?page=com.atlassian.jira.plug... ] Jonathan Fisher commented on DROOLS-4919: ----------------------------------------- Any reason why that SQL is being executed? It seems to want to read _the entire_ VariableInstanceLog table which can be quite large (we have a couple hundred thousand rows on it). Could the query be more optimized? > Long running query at kie-server startup > ---------------------------------------- > > Key: DROOLS-4919 > URL: https://issues.redhat.com/browse/DROOLS-4919 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.28.0.Final > Reporter: Danny Rucker > Assignee: Maciej Swiderski > Priority: Major > > The following query is executed at start up of kie-server > ``` > select vil.processInstanceId, vil.processId, vil.id, vil.variableId, vil.value from VariableInstanceLog vil where vil.id in (select MAX(v.id) from VariableInstanceLog v group by v.variableId, v.processInstanceId) > ``` > This is causing some issues with getting kie-server to start up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2440) CompositeMessage: add iteration

by Bela Ban (Jira)

Bela Ban created JGRP-2440: ------------------------------ Summary: CompositeMessage: add iteration Key: JGRP-2440 URL: https://issues.redhat.com/browse/JGRP-2440 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Make {{CompositeMessage}} implement {{Iterable<Message>}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2439) LongMessage

by Bela Ban (Jira)

Bela Ban created JGRP-2439: ------------------------------ Summary: LongMessage Key: JGRP-2439 URL: https://issues.redhat.com/browse/JGRP-2439 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 5.0 Message with a long as payload. This can for example be used to send/request credits in flow control -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 January 2020