drools-osgi-distribution zip gone
by Geoffrey De Smet
Note of warning for whoever is doing the next release:
The zip "Drools OSGi bundles" as seen on
http://www.jboss.org/drools/downloads
no longer exists.
It's been removed because:
- it's broken
- Our jars now support OSGi out-of-the-box
- We have an example in the repo droolsjbpm-integration how to use and
test drools with OSGi
(and that is far more reliable than what we had in
droolsjbpm-build-distribution)
13 years
Instant Drools Starter : Pack Publishing (Jeremy Ary)
by Mark Proctor
http://blog.athico.com/2013/03/instant-drools-starter-pack-publishing.html
We all start somewhere. My start with Drools came 5 years ago when I was tasked with maintaining some legacy rules and assisting with a new ground-up effort using the latest and greatest Drools release at the time. I dug through documentation, ordered every book I could find on the subject, and pestered Mark, Edson and others in the community willing to help way more than they probably cared for, but in the end, the community helped start me out with what I'd soon find to be my new obsession. Now, I feel like it's time for me to give something back.
If you're an architect, manager, or developer looking to evaluate or get started with Drools, you may find my new book, Drools Starter, to be a great way to get up and running quickly. I've done my best to compile all the basics needed to get a feel for working with the core engine into a brief, easy-to-digest guide. Here's some of what's covered inside:
Evaluate rules engines as a fit for your needs
Installing Drools and development tools
Authoring rule sets using the Drools Rule Language
Feeding information to your rules engine and evaluating rules
Understanding DRL syntax, operators, and functionality
Testing rules as a whole, individually, and for stability
Debugging the rule evaluation process visually and via logging
What modules make up the Drools system and the capabilities of each
Where to turn for more information and help
The book is currently available for pre-order (at a 20% discount!) over at Pack Publishing:
http://www.packtpub.com/getting-started-with-drools/book
I owe a large thanks to the community in helping me on my way through the last several years, especially to those in IRC and the mailing list who've aided with numerous predicaments and design choices along the way. Particular thanks to Mark, Edson and the rest of the development team for continued work on a great product and a great community, but especially to the two of you for spending too many hours in conversation online and at conferences helping myself and others like me find their way.
13 years
Freezing repositories drools + droolsjbpm-knowledge on Friday 15-MAR-2013
by Geoffrey De Smet
To fix the OSGi split-packages problem,
we'll be freezing the following repositories this Friday 15-MAR-2013:
droolsjbpm-knowledge
drools
A lot of package directory's will change on master.
*Please make sure you 've pushed all your local changes by Thursday
evening.*
Don't push on Friday - until I 've send a mail that's ok.
Most pull requests have been merged/closed in the last weeks (thanks to
Mario), so they don't go stale.
What will happen?
All kie-api.jar packages will be moved from
org.kie
to
org.kie.api
All kie-internal.jar packages will be moved from
org.kie
to
org.kie.internal
All drools-core.jar packages will be moved from
org.drools
to
org.drools.core
All drools-compiler.jar packages will be moved from
org.drools
to
org.drools.compiler
...
Why?
https://issues.jboss.org/browse/DROOLS-57
https://issues.jboss.org/browse/JBRULES-3574
13 years
Re: [rules-dev] Help with DefaultAgenda.Java
by Mark Proctor
Malory,
I'm replying here, rather than to your private email. We are an open source community, by asking these questions publicly it ensures all can participate and learn, and the conversations are archived for searching.
Your line numbers seem off. I'm looking at line 39 in DefaultConsequenceExceptionHandler:
https://github.com/droolsjbpm/drools/blob/5.4.x/drools-core/src/main/java...
Line 39 is the last argument of the method declaration. Also the only thing that could cause null pointer while handleException is if you were to pass a null Activation.
I think you are trying to do this too high up, where there is all sorts of thread safety issues you are exposing by putting Runnable around fireNextItem. There is shared states that those threads will access, which will cause problems.
Better to do it when the consequence is invoked directly:
activation.getConsequence().evaluate( this.knowledgeHelper, this.workingMemory );
Mark
On 10 Mar 2013, at 08:05, gmalathi.in(a)gmail.com wrote:
> Hi Mark,
>
> I have tried to change the source code of DefaultAgenda.Java by adding the code below:
>
> //drools orginial sequential code
> /*
> while ( continueFiring( fireLimit ) && fireNextItem( agendaFilter ) ) {
> fireCount++;
> fireLimit = updateFireLimit( fireLimit );
> this.workingMemory.executeQueuedActions();
> }
> */
>
>
> //code with concurrency
>
> InternalAgendaGroup myGroup = (InternalAgendaGroup) getNextFocus();
> fireCount = myGroup.size();
>
> for(int i =0; i< fireCount; ++i)
> {
>
> new Thread(new Runnable(){
> public void run()
> {
> fireNextItem( agendaFilter );
>
> }
> }).start();
>
> }
>
>
> I am getting an Errorjava.lang.NullPointerException because my code flow is going to consequenceExceptionHandler ! = null exception.
>
> else if ( this.consequenceExceptionHandler != null ) {
>
> this.consequenceExceptionHandler.handleException( activation, this.workingMemory.getKnowledgeRuntime(),
> e );
>
>
> Could you kindly help me with this?
>
> I am pasting the exception below and I am using Drools 5.4 Final version.
>
> In DA: [Activation rule=Rule 1, act#=0, salience=0, tuple=[fact 0:0:1773684356:1306428912:0:DEFAULT:org.drools.reteoo.InitialFactImpl@4dde85f0]
> ]
> Exception in thread "Thread-1" Exception in thread "Thread-0" Exception executing consequence for rule "Rule 1" in defaultpkg: java.lang.NullPointerException
> In DA WM: org.drools.impl.StatefulKnowledgeSessionImpl@542487b1
> In DA Errorjava.lang.NullPointerException
> In DA: [Activation rule=Rule 2, act#=1, salience=0, tuple=[fact 0:0:1773684356:1306428912:0:DEFAULT:org.drools.reteoo.InitialFactImpl@4dde85f0]
> ]
> In DA WM: org.drools.impl.StatefulKnowledgeSessionImpl@542487b1
> In DA Errorjava.lang.NullPointerException
> at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1208)
> at org.drools.common.DefaultAgenda$1.run(DefaultAgenda.java:1471)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1272)
> ... 3 more
> Exception executing consequence for rule "Rule 2" in defaultpkg: java.lang.NullPointerException
> at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1208)
> at org.drools.common.DefaultAgenda$1.run(DefaultAgenda.java:1471)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1272)
> ... 3 more
>
>
> Thanks a lot for the help.
>
> Regards,
> Malory
13 years
very unfriendly diagnostic after a simple error in a constraint
by Wolfgang Laun
(I'll try and create a simpler demo, but here's the original.)
when
Token( $elem: element ) // element is a MaSigType application object
AnyTrainSignal( x25no == $elem ) // x25 is an int
then
It's obvious that this is a user error (correct would be this ==
$elem). It results in the stack dump given below.
But the question is: does the diagnostic have to be the way it is? The
rule where the insert is doesn't help, and neither does the actual
class of the object. Normally, I'd expect that a compiler detects such
an error, as the Java compiler does.
-W
Caused by: org.drools.RuntimeDroolsException: Conversion to long not
supported from rss.bfz.cfg.jaxb.elrep.MaSigType
at org.drools.base.extractors.BaseObjectClassFieldReader.getLongValue(BaseObjectClassFieldReader.java:156)
at org.drools.base.ClassFieldReader.getLongValue(ClassFieldReader.java:167)
at org.drools.rule.VariableRestriction$LongVariableContextEntry.updateFromTuple(VariableRestriction.java:455)
at org.drools.common.SingleBetaConstraints.updateFromTuple(SingleBetaConstraints.java:108)
at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:91)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:146)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:158)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:215)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:330)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886)
at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:180)
at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:174)
at rss.ixl.route.Rule_ERS__start_collecting_elements_on_regular_route.defaultConsequence(Rule_ERS__start_collecting_elements_on_regular_route.java:12)
at rss.ixl.route.Rule_ERS__start_collecting_elements_on_regular_routeDefaultConsequenceInvoker.evaluate(Unknown
Source)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1091)
13 years
Drools Planner repository changes this Tuesday 2-MAR
by Geoffrey De Smet
Hi guys,
This Tuesday (2-MAR-2013), a few technical changes will occur due to
Drools Planner's namechange.
1) The github URL for Drools Planner will change from
https://github.com/droolsjbpm/drools-planner
to
https://github.com/droolsjbpm/optaplanner
2) The groupId's and artifactId's will change from
org.drools.planner:drools-planner-*
to
org.optaplanner:optaplanner-*
3) The directory names will change accordingly.
*If you have a clone/fork of the Drools Planner repository with changes,**
**it's best to send in any changes in a pull request for master by
Monday evening**
**if you want to avoid a having to port those changes manually.*
This namechange is the technical preparation for the more public
announcement we'll make in a few weeks.
To avoid speculation, you can read about the full explanation of the
rename to OptaPlanner below.
https://github.com/droolsjbpm/optaplanner-website/blob/master/community/D...
With kind regards,
Geoffrey De Smet
Drools Planner renamed to OptaPlanner
As of version |6.0.0.Beta1|, *Drools Planner has been renamed to
OptaPlanner*.
Why change the name?
OptaPlanner is the new name for Drools Planner. OptaPlanner is now
standalone, but can still be optionally combined with the Drools rule
engine for a powerful declarative approach to planning optimization.
*
OptaPlanner has graduated from the Drools
<http://www.jboss.org/drools> project to become a top-level JBoss
Community <http://www.jboss.org/> project.
o OptaPlanner (the planning engine) joins its siblings Drools (the
rule engine) and jBPM (the workflow engine) in the KIE group.
*
Our commitment to Drools hasn't changed.
o The efficient Drools rule engine is still the recommended way to
do score calculation.
o Alternative score calculation options, such as pure Java
calculation (no Drools), also remain fully supported.
How will this affect your business?
From a business point of view, there's *little or no change*:
*
The mission remains unchanged:
o We're still 100% committed to put /business resource
optimization/ in the hands of normal Java developers.
*
The license remains unchanged (Apache Software License 2.0). It's
still the same open source license.
*
Red Hat is considering support subscriptions offerings for
OptaPlanner as part of its BRMS
<http://www.redhat.com/products/jbossenterprisemiddleware/business-rules/>
and BPM platforms.
o A /Tech Preview/ of OptaPlanner is targeted for BRMS 6.0.
What has changed?
*
The website has changed to http://www.optaplanner.org
*
The distributions artifacts have changed name:
o
Jar names changes:
+ |drools-planner-core-*.jar| is now |optaplanner-core-*.jar|
+ |drools-planner-benchmark-*.jar| is now
|optaplanner-benchmark-*.jar|
o
Maven identification groupId's and artifactId's changes:
+ groupId |org.drools.planner| is now |org.optaplanner|
+ artifactId |drools-planner-core| is now |optaplanner-core|
+ artifactId |drools-planner-benchmark| is now
|optaplanner-benchmark|
o
As usual, for more information see the Upgrade Recipe in the
download zip.
*
The API's namespace has changed. As usual, see the Upgrade Recipe on
how to deal with this efficiently.
o Starting from 6.1.0.Final, OptaPlanner will have a 100%
backwards compatible API.
*
OptaPlanner gets its own IRC channels on Freenode
<http://freenode.net/>: |#optaplanner| and |#optaplanner-dev|
13 years
Re: [rules-dev] [rules-users] Can't obtain object from a FactHandle
by Wolfgang Laun
Hi Sotty,
thanks for the reply.
On 02/03/2013, Davide Sottara <dsotty(a)gmail.com> wrote:
> When **from** is used, there is no guarantee that the objects
> are part of the working memory - actually it is expected that they aren't,
> otherwise a memberOf constraint would have probably been used.
Possibly, but not necessarily. Again, all Ones and Twos are facts; but
now there is a subtle difference between
One( $list: listOfTwos ) Two(...) from $list
and
One( $list: listOfTwos ) Two( this memberOf $list )
because the former avoids looping when Two is updated on the RHS. (In
my particular case, I can't use the field to be changed in a
constraint to avoid looping. And I dislike of the attribute no-loop.)
> Tentatively looking up a possibly-but-unlikely-existing fact handle for
> each object would
> have impacted performance negatively, so it was decided that **from**
> would **always** create handles on the fly.
Well, here's where I'm well and truly miffed. It's all right if the
engine needs fact handles created on the fly for its happiness, but it
shouldn't give them to me, at least not without a clear indication
that they aren't "the real thing". And not documenting such possible
pitfalls is downright mean.
> Of course, I agree that the integrity of the WM (and thus of the
> universe) is broken,
> albeit in a minor way :).
It has cost me a hundred times the time that it would have taken to
add a warning to the Javadoc.
Cheers
Wolfgang
> We couldn't yet find a use case where this
> inconsistency
> would cause major issues.
> I'd move the discussion to the drools-dev list anyway, if a major
> problem - or
> an efficient solution - could be proposed.
> Best
> Davide
>
>
> On 03/02/2013 10:45 AM, Wolfgang Laun wrote:
>> Given a
>> org.drools.event.rule.BeforeActivationFiredEvent,
>> method getActivation() returns a
>> org.drools.runtime.rule.Activation
>> and its method getFactHandles() is documented to return a
>> List<FactHandle>.
>>
>> It should be possible to retrieve the fact object using
>> session.getObject( factHandle ), and this succeeds in many instances,
>> but not reliably (5.5.0-Final).
>>
>> Given facts of types One and Two a rule like
>> One( $list: listOFTwos )
>> Two(...) from $list
>> I find that Two facts, when matched via from, are not reported with
>> the proper fact handle, i.e., the one returned from the insert.
>>
>> What's the point in reporting fact handles that can't be used to
>> retrieve a fact object?
>>
>> If I want to obtain all facts that participate in an activation, is
>> method Activation.getObjects() more (and fully) reliable?
>>
>> -W
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
13 years