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)
                                
                         
                        
                                
                                12 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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.
                                
                         
                        
                                
                                12 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                12 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                12 years, 7 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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)
                                
                         
                        
                                
                                12 years, 8 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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|
                                
                         
                        
                                
                                12 years, 8 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
>
                                
                         
                        
                                
                                12 years, 8 months