I am working with drools expert 6.0.0.Beta3 (latest available on the downloads page) and I am trying to update a rule existing in the working memory. Basically, I am calling add() of kBuilder again, like so:
kBuilder.add(org.drools.io.ResourceFactory.newByteArrayResource(drl.getBytes()),
org.drools.builder.ResourceType.DRL);
When I first add the rule, it gets added, and is even triggered when conditions meet. However, when calling add() again, as above, I get the following exception:
java.lang.NullPointerException
at org.drools.compiler.compiler.PackageBuilder.validateUniqueRuleNames(PackageBuilder.java:1314)
at org.drools.compiler.compiler.PackageBuilder.initPackageRegistry(PackageBuilder.java:916)
at org.drools.compiler.compiler.PackageBuilder.addPackage(PackageBuilder.java:869)
at org.drools.compiler.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:474)
at org.drools.compiler.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:670)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:51)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:40)
at org.drools.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:34)
...
You are doing something wrong since trying to add the same DRL twice to the KnowledgeBuilder will end up in having the same rule twice in the KnowledgeBase. Honestly I'd be curious to know why you're trying this.
Anyway you should have a compilation issue reporting the duplicated rule name and not a NPE. This is definitively a bug that I reported here and already fixed on the master.
Thanks for having found this.
Related
I state that I am a beginner, here is my problem.
My model works perfectly when I run it with a normal simulation. Now I'm trying to optimize some parameters using the optimization experiment, I've followed all the steps of the official tutorial, but it doesn't work because I get "Exception during discrete event execution:
Truncated class file". The strange thing is that, looking into the console displaying the error, I see that some lines are referred to an old version of my model, for example:
java.lang.ClassFormatError: Truncated class file
at coffe_maker.Main._m1_1_delayTime_xjal(Main.java:14070)
The current model's name is coffee_maker_v2_6 so I don't understand why I get this kind of error, do you know if it is normal? What am I doing wrong?
The most likely cause is that you have Java code left in an 'unused' configuration of a Delay block's "Delay time" expression (e.g., it now has a static value but you had Java code in the now-switched-out dynamic value).
Unfortunately, AnyLogic sometimes still includes the switched-out code in the compiled class, and this can sometimes cause strange runtime errors such as that one.
If this does look to be the case, temporarily switch to the offending switched-out configuration and delete it before switching back to the correct one.
I have resolved: the problem was that, in every delay block of my model, the delay time was linked with a database reference (type code), now I am trying by tyiping the probability distributions in the delays directly and now the optimization works
I've just read the documentation here again, and it says the supervisor needs to explicitly check for the stop condition in the main loop, but it doesn't explain why it has to do so. What's the reason behind it?
So far for most of my code I've not included this condition and things still work fine. Is there a case I should be worried about here?
Also, if the condition is a standard code like:
if sv.should_stop():
sv.request_stop()
that has to be included every time a session was run, why couldn't it be included in a managed session by default? Meaning to say, is there a special use for writing this code explicitly in the for/while loop for training?
This is in case one of your queues becomes empty, or something else errors out and requires you to stop. If your queues are never empty and there are never any errors then you don't need to check.
So, I'm working on a SharePoint 2010 site that I developed, and I am trying to implement content type change propogation. During this process I seem to have found a strange bug. It seems my combination of calling methods in the SharePoint object model causes an infinite loop. You can see the code here (a little too large to post directly here I think): http://pastebin.com/U0qbLxpS. The key line there is on line 13. Leaving that line commented out results in an infinite loop of sub sites (starting at the first one). If I uncomment that line though, things seem to work fine. Does anyone have any experience with this bug or have any advice? Can anyone duplicate this issue for me? I was trying to use SPWeb.GetList("blah") instead of using SPWeb.List["blah"] directly as GetList is the recommended way to get access to a list (according to everything I have read). But this bug is a bit odd and is going to force me to leave a completely unrelated line of code in there (which leaves me feeling a bit strange).
My test site structure is this: http://localhost (main site) and http://localhost/ASubSite. The infinite loop happens on http://localhost/ASubSite and just keeps appending /ASubSite to the end and continuing the loop.
Thanks for any hope you can offer. If anyone can duplicate this, it would be great. Then maybe I can submit a bug to Microsoft about this. Otherwise, maybe this is just some strange combination of things I am doing combined with my site.
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.
Say you have the following code block:
if (Light.On) {
// do something...
} else if (Light.Off) {
// do something else...
} else {
// this state should never be reached
}
Now assume that the applications logic dictates that in this part of the code, the last state should never be reached, but it is not something that can be determined at compile time. And maybe there ARE other states (e.g. Light.Broken) which could be set by other parts of the application, but which are not used here.
What code do you add in the last else block?
Add no code, because it should not be reached anyway.
Add some logging functionality, so that you as a developer know that some illegal state has been reached.
Throw an exception, because the state must not be reached and if it is reached anyway, something else must be wrong.
The first option doesn't seem reasonable to me, hoping something goes right seems hardly the right choice. Option two has the advantage that your app doesn't crash right away, so if this happens in a rare occasion which was not caught in testing, the customer can continu using the application and the developer is notified of the problem. Option three causes the app to crash, which obviously is not something you want your customers to experience, but it does make it very clear that something is wrong.
What is the best way to handle such a situation?
EDIT, based on comments:
Some additional consideration to steer the discussion:
The contract of the method that contains the above code does not allow any other values to be set at that moment then On and Off.
Assume that the code is in a not-so-critical part of the application.
In development - fail hard and fail fast. Throw some kind of runtime exception, or just Assert(false).
In a release - shutdown gracefully. Your app is in an unusable state, and you cant realy on anything that you normally would, such as class invariants etc. Give the user a chance to save thir work, for example, try and log an error that could be sent back to the dev team and then shutdown.
EDIT: Based on comments added.
If the contract of the function states that the light shouold be on or off at function entry then any other state is an error. The function should fail, according to the principles outlined in my original answer.
Regarding the 'non-critical' aspaect - if a function precondition is not being met that means that your application is broken. Regardless of wether the error is detected in a non-critical piece of code, that does not imply that the problem itself is non-critical - you have no way of knowing that the bug that creates the invalid state doesnt also affect critical areas of code.
Well ... It depends. Having a third case for a boolean test would make me want to cry. It's just noise, adding confusion and telling me the developer was at least as confused as it makes me feel.
For a non-boolean, I guess you could do whatever ... If the ifs capture the states that are relevant to the code in question, there's no harm in just ignoring other cases. If there's a good chance that further cases will be needed in the future, a comment might be enough to indicate that for clarity.
As already said, in development phase you should make it visible as soon as possible. In release phase, it depends on how critical it is to reach this invalid state.
The least is to issue a log for debugging purpose.
Then you can try to recover from this invalid state either by going back to a previous valid state or by going to a new valid state.
Finally if nothing safe can be done, you can terminate the execution (with an alert to the user and a log to the maintainer).
3rd option is the correct as if for that part any other state is not valid so it should throw and exception saying invalid state.
Don't do anything. If all you care about is whether the light is on or not:
if (Light.On) {
// do some work
} else {
// too darned dark to work
}
Otherwise you should enumerate all your states.
If the other states are not allowed, you should error. If they're allowed but irrelevant, just ignore them. With properly designed code, there is no problem.
You're main problem here lies in a design that can have Light.On and Light.Off set at the same time. You should be using a state Light.State which is set to one of {on, flickering, off, broken, unplugged, exploded, emitting_dangerous_gamma_rays} and so on.
Throw an exception.
As you said, the third case should never occur. If it does happens, then something went wrong, and you don't know what else can be going wrong.
You also don't want calling code to think that code is working normally, when it is actually failing.
Additionally it makes it a lot easier to spot the issue Before it is released.
In the development version, just throw an exception.
In the release version:
Throw an exception
Save the user's work in some temporary file if possible
Save a crashdump and (using a small helper application) offer the user the option of sending it to you so you can identify and fix the problem