[JBoss JIRA] (DROOLS-1811) [Guided Decision Table] Column Wizard usability improvements
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-1811:
-------------------------------------
[~mstevens1] I uploaded screenshot taken with latest version of the wizard, the inputs are now explained quite well I think, however there is still question if some pages need to be reorganized somehow / what data / in what order should be shown.
> [Guided Decision Table] Column Wizard usability improvements
> ------------------------------------------------------------
>
> Key: DROOLS-1811
> URL: https://issues.jboss.org/browse/DROOLS-1811
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.2.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: UX
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-08 10-34-17.png
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard:
> - Placement of input fields
> -- *Field binding* should be on the same page as *Field*
> -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard
> - Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-1825:
----------------------------------------
Personally moving it to "Overview" should be avoided.. mainly because the "Overview" widget is used by ALL editors and customising it for GDT would be a PITA. It's also arguable that "Hit Policy" is something really specific and not part of the general "Overview" content. I think having the "Hit Policy" selector at the same place as the "Parent rule" selector (I'll attach a screen shot in the next comment.. just need to find it!). In the future there are other configurations specific to decision tables that would probably need including in the same place: Extended Entry/Limited Entry and orientation (rule as row/rule as column).
IIRC there is a JIRA somewhere to change the way columns are managed (moving the "Add" and "Edit" buttons to a new tab for "Columns"). It's possible this new tab could be re-purposed as "Configuration" that lists columns, hit policy, parent rule etc and provides the means to manipulate them.
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1811) [Guided Decision Table] Column Wizard usability improvements
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1811:
--------------------------------
Attachment: Screenshot from 2017-11-08 10-34-17.png
> [Guided Decision Table] Column Wizard usability improvements
> ------------------------------------------------------------
>
> Key: DROOLS-1811
> URL: https://issues.jboss.org/browse/DROOLS-1811
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.2.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: UX
> Fix For: 7.5.0.Final
>
> Attachments: Screenshot from 2017-11-08 10-34-17.png
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard:
> - Placement of input fields
> -- *Field binding* should be on the same page as *Field*
> -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard
> - Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-2113) [Guided Rule] From Accumulate using a List Field of a Data Object
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2113:
-----------------------------------
Summary: [Guided Rule] From Accumulate using a List Field of a Data Object
Key: DROOLS-2113
URL: https://issues.jboss.org/browse/DROOLS-2113
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor, Guided Rule Editor
Affects Versions: 7.5.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: Screenshot from 2017-11-08 10-23-50.png, Screenshot from 2017-11-08 10-31-41.png, Screenshot from 2017-11-08 10-31-58.png
There is problem if From Accumulate expression iterates over List field of a Data Object.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-9488:
------------------------------------
[~papegaaij] Thanks for info. I still don't understand how could wicket-cdi result in an additional bean deployment archive - it's a bean archive and does not seem to declare any CDI extension.
[~klaasjanb] Thanks. There is no official definition of "additional" bean archive. It's a way Weld attempts to solve some specific corner cases, e.g. a CDI extension does not have to be inside a bean archive. So if it adds an {{AnnotatedType}} or a {{Bean}}, it's not clear what bean archive it belongs to. Does the {{app-core.jar}} contain a {{beans.xml}} descriptor or a class with a [bean defining annotation|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining... If so, then it's a regular bean archive.
> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
> Key: WFLY-9488
> URL: https://issues.jboss.org/browse/WFLY-9488
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
> Reporter: Klaasjan Brand
> Assignee: Martin Kouba
> Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Klaasjan Brand (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Klaasjan Brand commented on WFLY-9488:
--------------------------------------
Our deployment structure is an ear bundle containing (among other artifacts) a Wicket webapp:
bundle.ear
\_ webapp.war
(contains the application as a jar package under /WEB-INF/lib/app-core.jar)
The webapp components as well as most of the injected beans (and certainly some with which I could reproduce this issue) are defined in the 'app-core' jar.
I can't find any definitive description of 'additional deployment'; is my assumption that the 'app-core.jar' is an additional deployment of the webapp.war correct?
> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
> Key: WFLY-9488
> URL: https://issues.jboss.org/browse/WFLY-9488
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
> Reporter: Klaasjan Brand
> Assignee: Martin Kouba
> Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Klaasjan Brand (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Klaasjan Brand edited comment on WFLY-9488 at 11/8/17 3:52 AM:
---------------------------------------------------------------
Our deployment structure is an ear bundle containing (among other artifacts) a Wicket webapp:
bundle.ear
\_ webapp.war
(contains the application as a jar package under /WEB-INF/lib/app-core.jar)
The webapp components as well as most of the injected beans (and certainly some with which I could reproduce this issue) are defined in the 'app-core' jar.
I can't find a clear description of 'additional deployment'; is my assumption that the 'app-core.jar' is an additional deployment of the webapp.war correct?
was (Author: klaasjanb):
Our deployment structure is an ear bundle containing (among other artifacts) a Wicket webapp:
bundle.ear
\_ webapp.war
(contains the application as a jar package under /WEB-INF/lib/app-core.jar)
The webapp components as well as most of the injected beans (and certainly some with which I could reproduce this issue) are defined in the 'app-core' jar.
I can't find any definitive description of 'additional deployment'; is my assumption that the 'app-core.jar' is an additional deployment of the webapp.war correct?
> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
> Key: WFLY-9488
> URL: https://issues.jboss.org/browse/WFLY-9488
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
> Reporter: Klaasjan Brand
> Assignee: Martin Kouba
> Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1771) Serialization is triggering rule multiple times
by Christopher Brecht (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1771?page=com.atlassian.jira.plugi... ]
Christopher Brecht commented on DROOLS-1771:
--------------------------------------------
Is this task under investigation in the actual sprint? Is there an estimated time for the fix?
> Serialization is triggering rule multiple times
> ------------------------------------------------
>
> Key: DROOLS-1771
> URL: https://issues.jboss.org/browse/DROOLS-1771
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.2.0.Final, 7.3.0.Final
> Reporter: Christopher Brecht
> Assignee: Mario Fusco
> Attachments: EventA.java, Person.java, Reproducer.java
>
>
> I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization.
> The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events.
> +*WITH SERIALIZATION *+
> STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010]
> +*WITHOUT SERIALIZATION *+
> STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months