[JBoss JIRA] (AS7-4207) Use specified comparison column as baseline in PlainColumnView
by Rob Cernich (JIRA)
Rob Cernich created AS7-4207:
--------------------------------
Summary: Use specified comparison column as baseline in PlainColumnView
Key: AS7-4207
URL: https://issues.jboss.org/browse/AS7-4207
Project: Application Server 7
Issue Type: Enhancement
Components: Console
Reporter: Rob Cernich
Assignee: Heiko Braun
Specifying a comparison column and baseline column is redundant. Using the value in the comparison column in the baseline is more flexible as it allows each row to specify its own baseline.
For example, in SwitchYard we display message statistics for the system and individual services within the system. For the service metrics, we would like the total count to display relative to the system total count, but have the success count relative to the total count for the service. With system total = 4, service total = 1, service success = 1, the service total ratio would be 25% and its success ratio would be 100%.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3330) Provide MoveFilter for generic factories
by Lukáš Petrovický (Created) (JIRA)
Provide MoveFilter for generic factories
----------------------------------------
Key: JBRULES-3330
URL: https://issues.jboss.org/browse/JBRULES-3330
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.4.0.Beta1
Reporter: Lukáš Petrovický
Assignee: Mark Proctor
At the moment, generic factories are far too generic - for most of the problems, an optimization can be found so that the amount of reasonable moves is significantly reduced. The intention is to allow customization of the generic move factories, while still using all their power. Generic move factory simply produces every possible move and the user defines, in a MoveFilter, which of them shouldn't be passed to the planner. The feature could work like this:
1. An interface is introduced, called eg. MoveFilter<T extends Move>. This interface declares one method - boolean filter(Solution solution, T move). This method accepts the solution of the MoveFactory, as well as the Move object that's been created by the MoveFactory. It returns true if the GenericMove should be included in the createMoveList() method of the MoveFactory, false otherwise.
(Please make sure that the MoveFilter type is generic, so that filter() always knows the correct type of the move without the user doing any magic or assumptions. This would most probably require making MoveFactory generic as well, but that could be useful.)
2. Implementations of the MoveFilter interface are annotated with @MoveFilter(factory = [SomeMoveFactory.class, SomeOtherMoveFactory.class]). This annotation would specify to which move factory this filter should be related. Some checks should be put in place that the annotation will only work when the MoveFilter and MoveFactory share the same Move type.
3. The same as in (2) can be achieved by specifying filters in the XML configuration of the solver, altough I personally don't like the XML configs much.
4. MoveFactory's createMoveList() method is enhanced so that it runs user-specified MoveFilters and excludes the filtered moves from the resulting MoveList.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months