Heh... this is definitely a workaround.. and not exactly an efficient one :)
You are essentially recreating your runtime environment from scratch...
a question now:
after you "make new KB the default KB", what happens to your session(s)?
Do you create a new one or do you keep using the previously instantiated
one?
The latter would be obviously wrong.. the former could be interesting.
A bit of background: when you update a KB and there are "live" sessions
with object
inserted, all the facts are implicitly re-updated to see if they can
match any
new rule that has potentially been added.
With your workaround, you lose all the state of the current session...
IF this is something you can do, I would suggest to try this: do not use
your
workaround, but make sure you DISPOSE any existing session(s) before
updating the KB (do not create a new one!) and only then create a new
SESSION to process your next facts.
If this never generates exceptions, it would possibly suggest that there is
indeed a race/overlap between the KB update and the (ongoing) propagation
of some fact.
Thanks!
Davide
p.s. what about the possibility of deploying a customized drools version?
On 05/15/2013 02:57 PM, mohdejaz74 wrote:
Apologize for being late to provide update ...
Basically I did a small workaround and it has worked fine so far.
So whenever a rule is added/updated, I perform following steps -
1. Create new KB
2. Add rule to this KB and check for errors
3. If no errors, then
Copy over the knowledge packages from previous KB to new KB
Make new KB as the default KB
End
So far I've not seen any of the previous exceptions (ClassCastException)
Regards
Ejaz
--
View this message in context:
http://drools.46999.n3.nabble.com/threw-error-java-lang-ClassCastExceptio...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users