[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, 10 months
[JBoss JIRA] (JBRULES-3556) Support mappings between trait and core class fields
by Davide Sottara (JIRA)
Davide Sottara created JBRULES-3556:
---------------------------------------
Summary: Support mappings between trait and core class fields
Key: JBRULES-3556
URL: https://issues.jboss.org/browse/JBRULES-3556
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-compiler, drools-core
Affects Versions: 5.4.0.Final
Reporter: Davide Sottara
Assignee: Davide Sottara
Priority: Minor
Fix For: 5.5.0.Beta1
Trait - Core field mapping requires the fields to have the same name and compatible types. Whenever the names cannot be the same, e.g. due to interface naming requirements, it could be desirable to define a custom mapping:
declare trait X
tfield : String @Alias("cField")
end
declare Y
cField : String
end
Here, tField should be mapped onto the hard field cField, even if the names are different
--
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, 10 months
[JBoss JIRA] (JBRULES-3596) KnowledgeBase Incremental Build does not manage compiled types correctly
by Davide Sottara (JIRA)
Davide Sottara created JBRULES-3596:
---------------------------------------
Summary: KnowledgeBase Incremental Build does not manage compiled types correctly
Key: JBRULES-3596
URL: https://issues.jboss.org/browse/JBRULES-3596
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler, drools-core
Affects Versions: 5.4.0.Final
Reporter: Davide Sottara
Assignee: Davide Sottara
Priority: Blocker
Fix For: 5.5.0.Beta1
The issue arises when a KnowledgeBuilder is initialized with a KnowledgeBase for incremental building.
Notice that this is what happens when a KnowledgeAgent is created setting the "useKBaseClassLoaderForCompiling" option.
The Kbuilder's PackageBuilder (~ line #1190) creates/gets a Package from the Rulebase, effectively adding the compilation results to the rulebase.
However, AbstractRuleBase.addPackages (~ line #510) is called before the packageDescr is really compiled, so the kbuilder's additions are not correct (the rewiring done by addPackages is not performed) and the package(s) generated by the packagebuilder must be readded to the rulebase.
However, the compiled resources (e.g. declared types) are not rewired properly, so the class mismatch between the ones used for compilation and
the ones used for runtime will prevent rules from firing.
--
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, 10 months