[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-1825:
--------------------------------------
[~manstis] might be right that the Overview is not the best since it is the same for all assets.
Still I don't really like the idea of this being placed in a location where you have the most common actions are done. Since changing the hit policy completely changes how the table is used. I imagine the most common changes will be from first order to resolved. Giving the user the freedom to change the rule order. So this is really rare.
Extended/limited change and parent rule would be in the same group with hit policy change. Used as often, something that has huge impact on the table visualization or table behavior.
Now even with all these ideas. I am not sure what the best fix is :) Could be some button/menu item that lists these table properties and gives the option to change 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
> Attachments: DROOLS-1825 (Parent Rule).png
>
> 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] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on WFLY-9488:
---------------------------------------
[~mkouba] {{app-core.jar}} does contain a {{beans.xml}} with {{bean-discovery-mode="annotated"}}. However, the classes involved are not beans. They are Wicket components and do not conform to the requirements of a CDI bean. For example, many don't have a default constructor as Wicket requires an String id as a parameter to the super constructor. These are instantiated from user code and injected from inside the super constructor by Wicket. The reason they end up in 'additional' probably is because they are not CDI beans but are injected as non-contextual objects.
> 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-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 updated DROOLS-1825:
-----------------------------------
Attachment: DROOLS-1825 (Parent Rule).png
> [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
> Attachments: DROOLS-1825 (Parent Rule).png
>
> 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] (WFLY-9535) wildfly 10.x not working on fedora 14 (32 bits)
by Manvendra Rai (JIRA)
Manvendra Rai created WFLY-9535:
-----------------------------------
Summary: wildfly 10.x not working on fedora 14 (32 bits)
Key: WFLY-9535
URL: https://issues.jboss.org/browse/WFLY-9535
Project: WildFly
Issue Type: Bug
Reporter: Manvendra Rai
Assignee: Jason Greene
Do not know if wildfly is compliant with fedora 14 (32 bits) ?
Here is what I'm doing -
Jboss ran as a service.
I installed wildfly.
Modify /etc/rc.d/init.d/jboss to pint on wildfly folder.
Reboot server.
Service jboss start is OK but nothing happen.
there is nothing in the log as to why this is happening.
--
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:
--------------------------------
Description:
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
- *[UPDATED SOLVED]*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.
was:
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.
> [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
> - *[UPDATED SOLVED]*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-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:
--------------------------------
Description:
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
- *[UPDATED SOLVED]* 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.
was:
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
- *[UPDATED SOLVED]*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.
> [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
> - *[UPDATED SOLVED]* 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