Quotes from javadoc of 6.0.0 Beta 3
by Wolfgang Laun
Quotes from Javadoc of 6.0.0 Beta 3
(1)
org.kie.api.builder Interface KieBuilder
"Sets the other KieModules from which the KieModule that has to be
built by this KieBuilder depends on"
"Sets the other Resources from which the KieModule that has to be
built by this KieBuilder depends on"
I had to read these several times... Does this mean:
The KieModule to be built by this KieBuilder depends on the given KieModules.
The KieModule to be built by this KieBuilder depends on the given Dependencies.
=*=*=
(2)
org.kie.api Interface KieBase
removeProcess(String processId)
Removes a process from the specified package.
Where is the "specified package"? Either javadoc is incorrect or the
parameter is missing.
=*=*=
(3)
Which English is it?
EqualityBehaviorOption getEqualsBehavior()
Returns the EqualityBehavior of this KieBaseModel
EqualityBehaviorOption - Enum in org.kie.api.conf
An Enum for EqualityBehavior option.
BUT
org.kie.api.management.KieBaseConfigurationMonitorMBean.getAssertBehaviour()
=*=*=
(4)
getClockType() - Method in interface org.kie.api.builder.model.KieSessionModel
Returns the EqualityBehavior of this KieSessionModel
REALLY?
=*=*=
(5)
execute(Iterable) - Method in interface
org.kie.api.runtime.rule.StatelessRuleSession
Execute a StatelessKnowledSession, iterate the Iterable inserting
each of it's elements.
=> its
(Several times.)
=*=*=
(6)
org.kie.api.runtime Interface KieRuntime
setGlobal(String identifier, Object value)
Sets a global value on the internal collection
Which "internal collection"? A global becomes an object in a KieSessions?
=*=*=
(7)
org.kie.api.runtime.rule Interface StatelessRuleSession
StatelessKnowledSession => Stateless?????Session
Rule? Knowledge? (Occurs several times.)
=*=*=
(8)
org.kie.api.runtime Class ClassObjectFilter
Filters Objects by Class, only accepting Classes of the specified type
=>
Filters objects by class, only accepting objects of the class
specified in the constructor
Returning true means the Iterator accepts, and thus returns, the
current Object's Class type.
=>
Returns true if the Iterator accepts the given object according to its class.
=*=*=
(9)
Package org.kie.api.runtime
The runtime engine classes, including StatefulKnowledgeSession and
StatelessKnowledgeSession.
StatelessKnowledgeSession and StatefulKnowledgeSession are gone now,
aren't they?
=*=*=
(10)
org.kie.api.runtime Interface CommandExecutor
Batch Executor allows for the scripting of of a Knowledge session
using Commands, both the StatelessKnowledgeSession and
StatefulKnowledgeSession implement this interface.
StatelessKnowledgeSession and StatefulKnowledgeSession are gone now,
aren't they?
=*=*=
(11)
org.kie.api.runtime Interface KieSessionConfiguration
(a)
KnowledgeSessionConfiguration A class to store Session related configuration
=>
A class to store a session related configuration.
(b)
KnowledgeSession => KieSession (?, occurs several times)
(c) Doesn't seem right:
...behaviour inside KnowledgeSession. drools.keepReference = drools.clockType =
=*=*=
(12)
Message is not a good choice. KieMessage would have been better...
=*=*=
-W
12 years, 4 months
RuleFlowGroups and AgendaGroups
by Mark Proctor
i've found that different semantics of RFGs (RuleFlowGroups) and AGs (AgendaGroups) to confuse people, especially because they can be used together. If you remember the idea was that an RFG was a staging ground for rules, when activated it would place all it's rules into the AG it was associated with, and trace those, when all it's rules had fired, it would de-activate.
If you used both RFGS and different AGs, the combinations could result in RFGs never returning. Multiple process instances on the same ksession can also interact with the same RFG, at different points of it's initial activation and end deactivation.
The concept of groups makes you think there is a some degree of isolation in the inferencing of rules within that group. Only for them to be "merged' into one single AG, either from an 'and' split or different executing process instances.
This behaviour makes using RFG's potentially non deterministic, and certainly not deterministic from looking at the rules in the one RFG alone.
Recently people wanted to be able to test RFGs without having to call the process, for testing purposes.
So I think we need to rethinking how we do this. My first initially step is to remove the ambiguities of the RFG and AG interaction, and merge them. So the rule has only one potently group name, and it's semantics are that of an AG, with the additional rule flow tracking call back. Now when an rule flow reaches an RFG it simply call setFocus(), and adds the tracking callback. So when the group pops the rule flow is notified, and allowed to continue.
>From within the same process instance this gives isolation as even in an 'and' it will execute each of the groups separately. However it doesn't solve the problem with regards to multiple process instance interaction, especially with regards to event models, or with how AGs can actually be on a stack multiple times.
So while i feel unifying the concepts is a step in the right direction, it does not solve everything, and I don't have all the answers yet…. so if anyone has thoughts on this, please share them :)
Mark
12 years, 5 months
The final nails in Guvnor's (repository) coffin
by Michael Anstis
Hi,
We've come to a stage, in between Betas, when I can complete the final
split work.
- droolsjbpm/guvnor/drools-wb is to move to a new repo
droolsjbpm/drools-wb
- droolsjbpm/guvnor/kie-wb-common is to move to a new repo
droolsjbpm/kie-wb-common
- droolsjbpm/guvnor/guvnor is to move to droolsjbpm/guvnor
I'll filter the folders to preserve history (that's the plan!)
All commits to droolsjbpm/guvnor need to be complete.
Please confirm when your topic branches can withstand the devastation that
is to follow.
No GAVS will be harmed in this final move.. it's just moving code to the
correct places now.
*Assuming this wil take a day or so, and assuming Beta 4 is next week.. I
need to do this starting Thursday.
*
Toni, Jervis, Walter - you're probably the most likely to have work to be
committed...
Please pass this on to who ever it could affect.
With kind regards,
Mike
12 years, 5 months
Walkin Clinic for Drools & jBPM @ Red Hat Summit
by Mark Proctor
http://blog.athico.com/2013/06/walkin-clinic-for-drools-jbpm-red-hat.html
Red Hat Summit, Boston
June 11th to 14th
We have a dedicated room for community members to come and chat and hang out with core Drools & jBPM developers. The room should be open to all, not just those with summit passes, although you'll need to tell security where you are going.
Day: Thursday
Location: Hynes Convention Centre, Hynes Room 110
There will be chairs and tables, so you can spend as long as you like. Myself, Edson Tirelli, Kris Verlaenen and Pedro Zapata will be there. No question too small, no task too big :) We can help you getting installed and set, give some mentoring on your current projects, or help you dive deep into Drools or jBPM code.
You can drop in with quick questions on your projects or about Drools & jBPM itself, there will be chairs and tables, so you can stay longer and hang out and code :)
12 years, 5 months
