July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ] Richard Achmatowicz edited comment on WFLY-11833 at 7/19/19 6:27 AM: --------------------------------------------------------------------- I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream. At present, the code in ProtocolV3ObjectResolver works like this: * when writing ("replacing") an Affinity object into the stream: ** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity ** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity * when reading ("resolving") an affinity object from the stream: ** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE ** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity What we are seeing in this issue is the case where: * when writing, Affinity.LOCAL is being replaced by the sender's NodeAffinity * when reading, the sender's NodeAffinity is replaced by the sender's URIAffinity was (Author: rachmato): I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream. At present, the code in ProtocolV3ObjectResolver works like this: * when writing ("replacing") an Affinity object into the stream: ** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity ** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity * when reading ("resolving") an affinity object from the stream: ** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE ** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity > Stateful Session Bean affinity URI instead of cluster > ----------------------------------------------------- > > Key: WFLY-11833 > URL: https://issues.jboss.org/browse/WFLY-11833 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 16.0.0.Final > Environment: WildFly cluster having SFSB deployed. > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: stateful-timeout.zip, test-debug-log.txt > > > Deployed is an application with the following setup: > * Containing a SFSB (_with passivationCapable="true"_) > * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB > Scenario: > A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned. > The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster. > See the attached Gradle reproducer application -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11833) Stateful Session Bean affinity URI instead of cluster

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-11833?page=com.atlassian.jira.plugin... ] Richard Achmatowicz commented on WFLY-11833: -------------------------------------------- I'm attaching a detailed log of test execution with just about everything written out: test-debug-log.txt One thing I discovered was that affinities are being processed even in the marshaling code (see ProtocolV3ObjectResolver). When a proxy is marshaled, certain affinities are substituted with other affinities using the class ProtocolV3ObjectResolver, depending on the endpoints of the connection handing the invocation. This is where the unexpected URI affinities are coming from in this example. The ObjectResolver keeps track, for the current connection, of the sender's NodeAffinity and URIAffinity, as well as the receiver's NodeAffinity and URIAffinity and uses these values in substitution of what goes into the stream and what comes out of the stream. At present, the code in ProtocolV3ObjectResolver works like this: * when writing ("replacing") an Affinity object into the stream: ** if the object corresponds to Affinity.LOCAL (and the sender's NodeAffinity exists) , replace Affinity.LOCAL with the sender's NodeAffinity ** if the object corresponds to the receiver's URIAffinity, replace the receiver's URIAffinity with the receiver's NodeAffinity * when reading ("resolving") an affinity object from the stream: ** if the object corresponds to Affinity.LOCAL, resolve this to the sender's URIAffinity (if we prefer URIs), or the sender's NodeAffinity (if it exists) or NONE ** if the object corresponds to the receiver's NodeAffinity, resolve this to Affinity.LOCAL, else if the object corresponds to the sender's NodeAffinity, resolve to the sender's URIAffinity > Stateful Session Bean affinity URI instead of cluster > ----------------------------------------------------- > > Key: WFLY-11833 > URL: https://issues.jboss.org/browse/WFLY-11833 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 16.0.0.Final > Environment: WildFly cluster having SFSB deployed. > Reporter: Joerg Baesner > Assignee: Richard Achmatowicz > Priority: Major > Labels: downstream_dependency > Attachments: stateful-timeout.zip, test-debug-log.txt > > > Deployed is an application with the following setup: > * Containing a SFSB (_with passivationCapable="true"_) > * A SLSB exposing a _remote_ method to a standalone client returning an instance of the SFSB > Scenario: > A standalone client is invoking the _remote_ method on the Stateless Session Bean and a new instance of the Stateful Session Bean is returned. > The issue is that the affinity of the returned Stateful Session Bean is URI instead of Cluster. > See the attached Gradle reproducer application -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4573) Support AuthenticationClient within deployment

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4573: ---------------------------------------- Summary: Support AuthenticationClient within deployment Key: WFCORE-4573 URL: https://issues.jboss.org/browse/WFCORE-4573 Project: WildFly Core Issue Type: Feature Request Components: Security Reporter: Darran Lofthouse This may actually be bigger than just security but for now this is more security related. The Elytron subsystem supports associating an AuthenticationContext with the classloader of every deployment - we should take this one step further and consider if the deployment contains a wildfly-config.xml use the configuration it contains instead. We may want one additional feature however and instead see if we can combine together and maybe even allow the deployment defined config to use the managed credential store. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFBUILD-47) Unsolvable artifact specifications are ignored

by Carlo de Wolf (Jira)

Carlo de Wolf created WFBUILD-47: ------------------------------------ Summary: Unsolvable artifact specifications are ignored Key: WFBUILD-47 URL: https://issues.jboss.org/browse/WFBUILD-47 Project: WildFly Build Tools Issue Type: Bug Affects Versions: 1.2.11.Final Reporter: Carlo de Wolf Assignee: Stuart Douglas If a feature-pack definition contains a reference to an artifact that is not resolvable, a broken feature pack is produced. The plugin should throw an error in this case, not continue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12301) CallerPrincipal will be anonymous (randomly) if EJB2 is called

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12301?page=com.atlassian.jira.plugin... ] Cheng Fang reassigned WFLY-12301: --------------------------------- Assignee: Darran Lofthouse (was: Cheng Fang) > CallerPrincipal will be anonymous (randomly) if EJB2 is called > -------------------------------------------------------------- > > Key: WFLY-12301 > URL: https://issues.jboss.org/browse/WFLY-12301 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 17.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Darran Lofthouse > Priority: Major > Labels: EJB2, security > Attachments: reproducer.zip > > > An EJB application which call an EJB2 SLSB will fail (randomly) to show the correct user if getCallerPrincipal is used inside. Also the roles are not set. > The EJB2 Bean is secured by ejb-jar.xml so it is not expected that it will be called without role > <assembly-descriptor> > <method-permission> > <role-name>testRole</role-name> > <method> > <ejb-name>simpleejb.server.SomeEJB2Bean</ejb-name> > <method-intf>Remote</method-intf> > <method-name>*</method-name> > </method> > </method-permission> > This error is constant seen if the server is up and running but each restart will change the behaviour randomly. > Note that an EJB3 bean of the same EAR file will work always correctly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12301) CallerPrincipal will be anonymous (randomly) if EJB2 is called

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12301?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12301: ----------------------------------- By following the steps and running the test.sh script included in reproducer, I was able to reproduce it with the recent WildFly build. If I replace jboss-ejb-client in the reproducer to be 4.0.21.Final (the current latest), the test still failed, but takes more rounds to reproduce than running with the original jboss-ejb-client (version 4.0.12.Final-redhat-00001). Not sure if this is significant data point. One of the bug fixes in 4.0.21.Final is EJBCLIENT-340 (Ensure any AuthenticationContext associated with the invocation is propagated to the transaction call.), not sure if it's related. >From various symptom described here (e.g., slight difference between running server vs restarted server, passed with default security config vs failed with elytron), I suspect the problem is at server side security context intake, rather than at the client side propagation. [~dlofthouse] can you take a look? > CallerPrincipal will be anonymous (randomly) if EJB2 is called > -------------------------------------------------------------- > > Key: WFLY-12301 > URL: https://issues.jboss.org/browse/WFLY-12301 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 17.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Cheng Fang > Priority: Major > Labels: EJB2, security > Attachments: reproducer.zip > > > An EJB application which call an EJB2 SLSB will fail (randomly) to show the correct user if getCallerPrincipal is used inside. Also the roles are not set. > The EJB2 Bean is secured by ejb-jar.xml so it is not expected that it will be called without role > <assembly-descriptor> > <method-permission> > <role-name>testRole</role-name> > <method> > <ejb-name>simpleejb.server.SomeEJB2Bean</ejb-name> > <method-intf>Remote</method-intf> > <method-name>*</method-name> > </method> > </method-permission> > This error is constant seen if the server is up and running but each restart will change the behaviour randomly. > Note that an EJB3 bean of the same EAR file will work always correctly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4346) Provide fixed code for Kie Client usage in docs

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-4346: -------------------------------------- Summary: Provide fixed code for Kie Client usage in docs Key: DROOLS-4346 URL: https://issues.jboss.org/browse/DROOLS-4346 Project: Drools Issue Type: Task Reporter: Edoardo Vacchi Assignee: Edoardo Vacchi https://issues.jboss.org/browse/BXMSDOC-4259 code for client usage does not compile, throws exception -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4346) Provide fixed code for Kie Client usage in docs

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4346?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-4346: ----------------------------------- Sprint: 2019 Week 29-31 > Provide fixed code for Kie Client usage in docs > ----------------------------------------------- > > Key: DROOLS-4346 > URL: https://issues.jboss.org/browse/DROOLS-4346 > Project: Drools > Issue Type: Task > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core > > https://issues.jboss.org/browse/BXMSDOC-4259 code for client usage does not compile, throws exception -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4272) Blog post about Rule Units

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4272?page=com.atlassian.jira.plugi... ] Edoardo Vacchi resolved DROOLS-4272. ------------------------------------ Resolution: Done http://blog.athico.com/2019/07/kogito-ergo-rules-part-1-bringing.html > Blog post about Rule Units > -------------------------- > > Key: DROOLS-4272 > URL: https://issues.jboss.org/browse/DROOLS-4272 > Project: Drools > Issue Type: Bug > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core, kogito, submarine > Fix For: 8.0.0.Final > > > describe the design of the doc DROOLS-3819 in a publicly-available blog post for general public consumption -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4256) IncrementalRuleCodegen should generate all related rules when one DRL file is changed

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4256?page=com.atlassian.jira.plugi... ] Edoardo Vacchi resolved DROOLS-4256. ------------------------------------ Resolution: Done > IncrementalRuleCodegen should generate all related rules when one DRL file is changed > ------------------------------------------------------------------------------------- > > Key: DROOLS-4256 > URL: https://issues.jboss.org/browse/DROOLS-4256 > Project: Drools > Issue Type: Task > Reporter: Mario Fusco > Assignee: Edoardo Vacchi > Priority: Major > > At the moment hot reload of Kogito extesnsion for Quarkus only works when modifying an existing rule. It should also work when new rules (or entire drl files) are added or removed. > Solution: we allow to codegen all the related files when compilation is re-triggered. The solution entails reworking IncrementalRuleCodegen -- with the occasion, we will be able to refactor so that this class is used everywhere rule codegen is done (including maven plugin and tests) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

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 July 2019