[JBoss JIRA] (WFLY-12674) placeholder for deferDetach issue
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Description:
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
was:
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
[jpa-spec users] [jsr338-experts] Re: changes for 7.6.2 Container-managed Transaction-scoped Persistence Context
This message: [ Message body ] [ More options (top, bottom) ]
Related messages: [ Next message ] [ Previous message ] [ In reply to ] [ Next in thread ] [ Replies ]
Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Tue, 29 Nov 2011 15:48:53 -0800
On 11/29/2011 12:15 PM, Scott Marlow wrote:
> On 11/29/2011 02:19 PM, Linda DeMichiel wrote:
>>
>>
>> On 11/29/2011 11:06 AM, Scott Marlow wrote:
>>> Hi Linda,
>>>
>>>>
>>>> Perhaps I am failing to grasp your concern here, but I see the intention
>>>> of the last
>>>> paragraph of section 7.6.2 as specifying the user-visible behavior that
>>>> is required
>>>> to result. Your paragraph above describes a possible implementation
>>>> strategy to
>>>> achieve it, but I don't think the spec needs to include that.
>>>>
>>>
>>>
>>> I think that the current 7.6.2 wording "detached at the end of the
>>> method call", is ambiguous about which method call is
>>> intended (the entity manager method invocation or the container level
>>> method invocation.)
>>>
>>> I think that clarifying it with one of the following changes, would
>>> eliminate the ambiguity.
>>>
>>> Updated proposal for last paragraph in 7.6.2:
>>>
>>> "
>>> If the entity manager is invoked outside the scope of a transaction,
>>> any entities loaded from the database will
>>> immediately become detached at the end of the container level method
>>> invocation call.
>>> "
>>
>> Just to be very clear.... What are you referring to by "container level
>> method
>> invocation call"? The call to the entity manager proxy?
>
> Not the call to the entity manager proxy. I mean the code that is calling the entity manager proxy (e.g. a session bean
> calling the entity manager proxy.)
>
> Perhaps a clearer proposal could be:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the container level method invocation call (e.g. when the session bean method
> ends).
> "
Ah, thanks. That is not the intended semantics. Rather it is that the
persistence context is created to service the method call that is made
on the entity manager only. It doesn't have the duration of a business
method invocation.
>
>>
>> thanks,
>>
>> -Linda
>>
>>
>>>
>>> Regards,
>>> Scott
{code}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...]
> placeholder for deferDetach issue
> ---------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12674) placeholder for deferDetach issue
by Scott Marlow (Jira)
Scott Marlow created WFLY-12674:
-----------------------------------
Summary: placeholder for deferDetach issue
Key: WFLY-12674
URL: https://issues.jboss.org/browse/WFLY-12674
Project: WildFly
Issue Type: Task
Components: JPA / Hibernate
Reporter: Scott Marlow
Assignee: Scott Marlow
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
[jpa-spec users] [jsr338-experts] Re: changes for 7.6.2 Container-managed Transaction-scoped Persistence Context
This message: [ Message body ] [ More options (top, bottom) ]
Related messages: [ Next message ] [ Previous message ] [ In reply to ] [ Next in thread ] [ Replies ]
Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Tue, 29 Nov 2011 15:48:53 -0800
On 11/29/2011 12:15 PM, Scott Marlow wrote:
> On 11/29/2011 02:19 PM, Linda DeMichiel wrote:
>>
>>
>> On 11/29/2011 11:06 AM, Scott Marlow wrote:
>>> Hi Linda,
>>>
>>>>
>>>> Perhaps I am failing to grasp your concern here, but I see the intention
>>>> of the last
>>>> paragraph of section 7.6.2 as specifying the user-visible behavior that
>>>> is required
>>>> to result. Your paragraph above describes a possible implementation
>>>> strategy to
>>>> achieve it, but I don't think the spec needs to include that.
>>>>
>>>
>>>
>>> I think that the current 7.6.2 wording "detached at the end of the
>>> method call", is ambiguous about which method call is
>>> intended (the entity manager method invocation or the container level
>>> method invocation.)
>>>
>>> I think that clarifying it with one of the following changes, would
>>> eliminate the ambiguity.
>>>
>>> Updated proposal for last paragraph in 7.6.2:
>>>
>>> "
>>> If the entity manager is invoked outside the scope of a transaction,
>>> any entities loaded from the database will
>>> immediately become detached at the end of the container level method
>>> invocation call.
>>> "
>>
>> Just to be very clear.... What are you referring to by "container level
>> method
>> invocation call"? The call to the entity manager proxy?
>
> Not the call to the entity manager proxy. I mean the code that is calling the entity manager proxy (e.g. a session bean
> calling the entity manager proxy.)
>
> Perhaps a clearer proposal could be:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the container level method invocation call (e.g. when the session bean method
> ends).
> "
Ah, thanks. That is not the intended semantics. Rather it is that the
persistence context is created to service the method call that is made
on the entity manager only. It doesn't have the duration of a business
method invocation.
>
>>
>> thanks,
>>
>> -Linda
>>
>>
>>>
>>> Regards,
>>> Scott
{code}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton edited comment on DROOLS-4625 at 10/15/19 12:06 PM:
----------------------------------------------------------------------
[~danielezonca] I proposed the icon (though could be another visual cue?) at the tab level to address your concern: " We already know how to show a wrong value (red background in the cell) but it will be in another tab so I guess we should warn the user of that otherwise he will see you scenario failures but no red cells.":
* The icon at the tab level could replace the need for the pop-over solution that you had proposed:
"We can create a popup with a message like "There are errors in Background data. Do you want to open background tab? Yes/No" or maybe open background tab directly or maybe other?"
Based on your comments, I assumed that the background would also indicate errors within it (red background in the cell.) I agree, it could be helpful to also indicate background errors on the test report panel.
was (Author: uxdlc):
[~danielezonca] I proposed the icon (though could be another visual cue?) at the tab level to address your concern: " We already know how to show a wrong value (red background in the cell) but it will be in another tab so I guess we should warn the user of that otherwise he will see you scenario failures but no red cells.":
* The icon at the tab level could replace the need for the dialog as you had proposed:
"We can create a popup with a message like "There are errors in Background data. Do you want to open background tab? Yes/No" or maybe open background tab directly or maybe other?"
Based on your comments, I assumed that the background would also indicate errors within it (red background in the cell.) I agree, it could be helpful to also indicate background errors on the test report panel.
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4625:
-------------------------------------------
[~danielezonca] I proposed the icon (though could be another visual cue?) at the tab level to address your concern: " We already know how to show a wrong value (red background in the cell) but it will be in another tab so I guess we should warn the user of that otherwise he will see you scenario failures but no red cells.":
* The icon at the tab level could replace the need for the dialog as you had proposed:
"We can create a popup with a message like "There are errors in Background data. Do you want to open background tab? Yes/No" or maybe open background tab directly or maybe other?"
Based on your comments, I assumed that the background would also indicate errors within it (red background in the cell.) I agree, it could be helpful to also indicate background errors on the test report panel.
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12669) Clustering: scattered cache errors
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12669?page=com.atlassian.jira.plugin... ]
Tommasso Borgato updated WFLY-12669:
------------------------------------
Description:
The issue is about scattered cache replication across cluster nodes;
WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following {{cli}} script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
{noformat}
The test is run with [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...]; the same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] do not have any problem; hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a *sampling error*;
Using MOD_JK as load balancer, we have a *22.46%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
Using HAPROXY as load balancer, we have a *1.71%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
Using MOD_CLUSTER as load balancer, we have a *1.85%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
On the server we deploy, as usual, {{clusterbench}} (see attachment clusterbench-ee8.ear).
was:
The issue is about scattered cache replication across cluster nodes;
WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following {{cli}} script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
{noformat}
The test is run with [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...]; the same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] do not have any problem; hence this looks like a regression;
As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a *sampling error*;
Using MOD_JK as load balancer, we have a *22.46%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
Using HAPROXY as load balancer, we have a *1.71%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
- OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
- ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
On the server we deploy, as usual, {{clusterbench}} (see attachment clusterbench-ee8.ear).
> Clustering: scattered cache errors
> ----------------------------------
>
> Key: WFLY-12669
> URL: https://issues.jboss.org/browse/WFLY-12669
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: clusterbench-ee8.ear
>
>
> The issue is about scattered cache replication across cluster nodes;
> WildFly is started in clustered mode using a scattered cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following {{cli}} script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
> {noformat}
> The test is run with [wildfly-18.0.0.Final.zip|https://download.jboss.org/wildfly/18.0.0.Final...]; the same tests run with version [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final...] do not have any problem; hence this looks like a regression;
> As usual, we test that the serial value stored in the scattered cache is incremented at every call: when this is not true, we say we have a *sampling error*;
> Using MOD_JK as load balancer, we have a *22.46%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> Using HAPROXY as load balancer, we have a *1.71%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> Using MOD_CLUSTER as load balancer, we have a *1.85%* of *sampling errors* with wildfly-18.0.0.Final.zip (0% with wildfly-17.0.1.Final.zip):
> - OK [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-17.0.1.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> - ERROR [eap-7.x-clustering-http-session-shutdown-scattered with wildfly-18.0.0.Final.zip|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.red...]
> On the server we deploy, as usual, {{clusterbench}} (see attachment clusterbench-ee8.ear).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4625:
-------------------------------------------
Thanks [~ederign], so [~danielezonca] then this might be possible? ^^
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4625) Scenario Test: UX for background data error reporting
by Eder Ignatowicz (Jira)
[ https://issues.jboss.org/browse/DROOLS-4625?page=com.atlassian.jira.plugi... ]
Eder Ignatowicz commented on DROOLS-4625:
-----------------------------------------
Hi [~uxdlc] this looks like more a specific editor requirement.
> Scenario Test: UX for background data error reporting
> -----------------------------------------------------
>
> Key: DROOLS-4625
> URL: https://issues.jboss.org/browse/DROOLS-4625
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Jozef Marko
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: background-error.png
>
>
> As a user I want to be informed about errors that occurred in the data I provided in the new *Background* tab. For more details about the *Backround* tab please see DROOLS-4162 and BAPL-1401.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
