[rules-users] java.lang.NullPointerException at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:56)

[Wolfgang Laun]

@Vincent: I'm concerned about the first stack trace line, which is
where no executable code can be. Clear this up first...

Sure it's possible that there is a bug. But it's hidden deep. Could be
some inconsistency between the Guvnor build and the deploying system.
I'm inclined to believe that the same app might work nicely if
everything were compiled locally.

-W


On 24/07/2012, Vincent LEGENDRE <vincent.legendre at eurodecision.com> wrote:
> I guess that entryPoints is a map that you build at init.
> Are you sure that the entry points in it are in sync with the actual session
> ?
> Why not using kSession.getWorkingMemoryEntryPoint(name).insert(...) directly
> ?
>
> @Wolfgang : Why can't there be a bug in NamedEntryPoint.insert(...) ? Having
> a NPE here is problematic, especially for a internal variable got from
> inside the same internal method. May be this is not called a bug, but at
> least the exception should be more explicative..
>
> Best guess for now is that the problem is inside your code (dont know where)
> and not inside drools code. The NPE, even if it should have been more user
> friendly, is certainly just a consequence of a bad usage somewhere. If it
> works well using DRL, and not using Guvnor, it may be a good track to
> follow. If you have the same usage (session creation, inserts, fire ...),
> then you have differences between the two ruleset (rules and/or model is
> different). With Guvnor, you can also download the "source" (just like a big
> DRL) instead of the pkg. This can be a solution too.
>
>
> ----- Mail original -----
>
> De: "Carolina Pellecchia" <carolina.pellecchia at gmail.com>
> À: "Rules Users List" <rules-users at lists.jboss.org>
> Envoyé: Mardi 24 Juillet 2012 14:27:34
> Objet: Re: [rules-users] java.lang.NullPointerException at
> org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:56)
>
>
>
> The entryPoint and obs aren't null. I'm sorry, where do you see the error?
>
>
> Carolina
>
> 2012/7/24 Wolfgang Laun < wolfgang.laun at gmail.com >
>
>
> Well, then it's a bug in your code. Do we all agree on this now?
>
> -W
>
>
>
> On 24/07/2012, Carolina Pellecchia < carolina.pellecchia at gmail.com > wrote:
>
>>>>If there is an insert() call in
>>>>org.tass.utils.ExpertSystemManager.java in line 156 then *this* is
>>>>where the insert occurs, not the insert() in the rule.
>>
>> org.tass.utils.ExpertSystemManager.java is our class and the source code
>> is
>> this:
>>
>> 153. *public* *void* insertObservation(String entryPoint,
>> Observation obs) {
>>
>>
>> 154. *try* {
>>
>> 155. *if*(entryPoints.containsKey(entryPoint)) {
>
>>
>> 156. entryPoints.get(entryPoint).insert(obs);
>>
>> 157.
>>
>> 158. ksession.fireAllRules();
>>
>> 159. }
>>
>> 160. }
>>
>> 161. *catch* (Exception e) {
>
>
>>
>> 162. logger.error(e, e);
>>
>> 163. }
>>
>> 164. }
>>
>>>>Where is org.tass.utils coming from?
>>
>> Where is org.tass.utils coming from? it is our class.
>>
>>
>>>>It's still a mystery to me how it's possible to have a stack trace
>>>>element from NamedEntryPoint.java line 48 - there's no code in this
>>>>line.
>>
>>
>> I agree, at the line 48 there isn't code. It would seem that "Drools 5.3.0
>>
>> final" has different binary and source code.
>>
>>
>>>>There is another mystery : why this is working when getting rules from a
>>>>
>> DRL file and not from Guvnor ...
>>>>Did you add the POJO model into the Guvnor's package ?
>>
>>
>> Yes, I did.
>>
>>>>But if this is it, package compilation should raise a compilation error
>> ...
>>
>>
>> The package compilation is ok.
>>
>>
>>>>What is sure is that the problem does not comes from the rules, as the
>> stack trace shows an "insert" call outside the rules, otherwise there
>> would
>> be a >>reteoo...ConsequenceInvocator (something like that) before ..
>>
>>
>> yes, It is sure
>>
>>
>>>>And a last question : is "org.tass.utils.ExpertSystemManager" a class
>> from you, or does it take place into another third-party framework (that
>> could use a >>different or modified version of drools).
>>
>>
>> org.tass.utils.ExpertSystemManager.java is our class. We aren't using
>> third-party
>> framework.
>>
>>
>> Thank you
>>
>> Carolina
>>
>>
>> 2012/7/23 Vincent LEGENDRE < vincent.legendre at eurodecision.com >
>>
>>> There is another mystery : why this is working when getting rules from a
>>>
>>> DRL file and not from Guvnor ...
>>> Did you add the POJO model into the Guvnor's package ?
>>> But if this is it, package compilation should raise a compilation error
>>> ...
>>>
>>> What is sure is that the problem does not comes from the rules, as the
>>> stack trace shows an "insert" call outside the rules, otherwise there
>>> would
>>> be a reteoo...ConsequenceInvocator (something like that) before ..
>>>
>>> And a last question : is "org.tass.utils.ExpertSystemManager" a class
>>> from
>>> you, or does it take place into another third-party framework (that could
>>>
>>> use a different or modified version of drools).
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>