[JBoss JIRA] (DROOLS-3779) DMN DT Analysis Subsumption&Contraction for DMN Decision Table
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-3779?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-3779:
-----------------------------------
Description:
Subsumption: rules that could be combined in a DMN Decision Table (because of subsumption)
Contraction: rules that could be combined because "adjacent"
was:Subsumption: rules that could be combined in a DMN Decision Table
> DMN DT Analysis Subsumption&Contraction for DMN Decision Table
> --------------------------------------------------------------
>
> Key: DROOLS-3779
> URL: https://issues.jboss.org/browse/DROOLS-3779
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Subsumption: rules that could be combined in a DMN Decision Table (because of subsumption)
> Contraction: rules that could be combined because "adjacent"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[JBoss JIRA] (DROOLS-3954) Document UX solutions for communicating errors in graphs & grids.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3954?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-3954:
-------------------------------------------
[~zhutaojiajia] I created this jira to document the design solutions for error presentation. Given that we'll be sharing the solution across 3 scrum teams, it will be easier to have a central document to reference. I'll set up a doc template. Then will ask for your help in populating it, if that sounds okay. :)
> Document UX solutions for communicating errors in graphs & grids.
> ------------------------------------------------------------------
>
> Key: DROOLS-3954
> URL: https://issues.jboss.org/browse/DROOLS-3954
> Project: Drools
> Issue Type: Task
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
>
> Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[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 4/30/19 9:47 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how should it be modified? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect *the configuration* of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say (e.g. whether a Remote or Local interface was used to create the bean).
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how should it be modified? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect *the configuration* of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> 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
>
>
> 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)
5 years
[JBoss JIRA] (DROOLS-3954) Document UX solutions for communicating errors in graphs & grids.
by Elizabeth Clayton (Jira)
Elizabeth Clayton created DROOLS-3954:
-----------------------------------------
Summary: Document UX solutions for communicating errors in graphs & grids.
Key: DROOLS-3954
URL: https://issues.jboss.org/browse/DROOLS-3954
Project: Drools
Issue Type: Task
Components: DMN Editor, Scenario Simulation and Testing
Reporter: Elizabeth Clayton
Assignee: Elizabeth Clayton
Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years
[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 4/30/19 9:36 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how should it be modified? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> 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
>
>
> 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)
5 years
[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 4/30/19 9:36 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how should it be modified? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect *the configuration* of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how should it be modified? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> 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
>
>
> 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)
5 years
[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 4/30/19 9:35 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this apply if the bean is also clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> 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
>
>
> 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)
5 years
[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 4/30/19 9:35 AM:
---------------------------------------------------------------------
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. That could be sensible restriction on the use of the proxy. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
was (Author: rachmato):
I've been looking at this and it may be tricky to fix. A client makes a remote invocation on a SLSB. That SLSB contains an injected reference to a SFSB home interface. The SLSB method uses the home interface to create an instance of the SFSB and return the proxy as a result of the invocation by the client.
The proxy returned by calling create() on the home interface has (strong affinity, weak affinity) = (LOCAL, LOCAL). By the time the proxy gets back to the client, as a return value, it has (strong affinity, weak affinity) = (URI, URI).
Affinity.LOCAL is defined as "the (affinity) specification for the local EJB environment". URIAffinity is defined as "the affinity specification corresponding to the given URI".
So, if a proxy has its affinity set to LOCAL, then it should not be able to invoke on any bean instances outside of its local EJB environment; which I would understand to the the EJB container it is invoked from (if any). That kind of makes sense, if we create a proxy within a deployment on a server which also has a SFSB deployed; in that case, the proxy is limited to making invocations on that local SFSB. Should this also apply if the bean is clustered? Perhaps. Why? We support fail-over behavior of proxies created from remote clients and created from deployments involving server-to-server clients. Need to clarify.
Certainly, if the proxy created is returned to the client, the affinity needs to be modified; if it were not, the proxy could not be used on the client to invoke on anything as the client does not have a local EJB environment. But how? Should it keep its affinity to that particular bean on that particular server, respecting *the context* in which it was created? Or should it respect the configuration of the bean (say clustered) that it references?
Investigating. Maybe the spec has something to say.
> 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
>
>
> 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)
5 years