KieContainer#updateToVersion fails when both versions of a drl file contain an event type declaration for an existing class

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

KieContainer#updateToVersion fails when both versions of a drl file contain an event type declaration for an existing class

mikedev9000
I am using the latest drools 6.1.0-SNAPSHOT. I have two jars containing different versions of a KieModule, and they each contain a drl file with an event type declaration for an existing class. If I try to update the container from one version to the other, the call to KieContainer#updateToVersion returns a Results instance that contains errors related to the @timestamp attribute on that event declaration. Here is an example of the error message: "[Message [id=1, level=ERROR, path=r0.drl, line=3, column=0
   text=Error creating field accessors for timestamp field 'mytime' for type 'FooEvent']]".

The following .patch file can be used to add a unit test to the IncrementalCompilationTest.java file that demonstrates this problem.

test_container_update_problem.patch

After applying the patch, and running this unit test, I see the following test failure:


java.lang.AssertionError: Errors detected on updateToVersion: [Message [id=1, level=ERROR, path=r0.drl, line=3, column=0
   text=Error creating field accessors for timestamp field 'mytime' for type 'FooEvent']]
        at org.junit.Assert.fail(Assert.java:88)
        at org.junit.Assert.assertTrue(Assert.java:41)
        at org.junit.Assert.assertFalse(Assert.java:64)
        at org.drools.compiler.integrationtests.IncrementalCompilationTest.testUpdateWithDeclarationPresent(IncrementalCompilationTest.java:95)



This error makes it nearly impossible for me to rely on and use KieContainer#updateToVersion, because I need to allow frequent changes to be made to drl files at run time, and I would prefer not to recreate the KieContainer, and all of its KieBases and KieSessions on every update.

Is this a known issue? If so, are there plans to fix it before the 6.1.0.Final release?
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] KieContainer#updateToVersion fails when both versions of a drl file contain an event type declaration for an existing class

Mark Proctor
Looks like a bug. Please try on 6.1CR1.
http://mvnrepository.com/artifact/org.drools

If it’s not fixed, and yo want it fixed you’ll need to submit a pull request with a failing unit test:
http://docs.jboss.org/drools/release/5.6.0.Final/droolsjbpm-introduction-docs/html/gettingstarted.html

You can see unit tests for incremental updates here:
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/IncrementalCompilationTest.java

Please try and add your unit test to that class, in the same format as the other tests.

Mark
On 18 Jun 2014, at 20:30, mikedev9000 <[hidden email]> wrote:

> I am using the latest drools 6.1.0-SNAPSHOT. I have two jars containing
> different versions of a KieModule, and they each contain a drl file with an
> event type declaration for an existing class. If I try to update the
> container from one version to the other, the call to
> KieContainer#updateToVersion returns a Results instance that contains errors
> related to the @timestamp attribute on that event declaration. Here is an
> example of the error message: "[Message [id=1, level=ERROR, path=r0.drl,
> line=3, column=0
>   text=Error creating field accessors for timestamp field 'mytime' for type
> 'FooEvent']]".
>
> The following .patch file can be used to add a unit test to the
> IncrementalCompilationTest.java file that demonstrates this problem.
>
> test_container_update_problem.patch
> <http://drools.46999.n3.nabble.com/file/n4030100/test_container_update_problem.patch>  
>
> After applying the patch, and running this unit test, I see the following
> test failure:
>
>
> java.lang.AssertionError: Errors detected on updateToVersion: [Message
> [id=1, level=ERROR, path=r0.drl, line=3, column=0
>   text=Error creating field accessors for timestamp field 'mytime' for type
> 'FooEvent']]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at
> org.drools.compiler.integrationtests.IncrementalCompilationTest.testUpdateWithDeclarationPresent(IncrementalCompilationTest.java:95)
>
>
>
> This error makes it nearly impossible for me to rely on and use
> KieContainer#updateToVersion, because I need to allow frequent changes to be
> made to drl files at run time, and I would prefer not to recreate the
> KieContainer, and all of its KieBases and KieSessions on every update.
>
> Is this a known issue? If so, are there plans to fix it before the
> 6.1.0.Final release?
>
>
>
>
> --
> View this message in context: http://drools.46999.n3.nabble.com/KieContainer-updateToVersion-fails-when-both-versions-of-a-drl-file-contain-an-event-type-declaratios-tp4030100.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] KieContainer#updateToVersion fails when both versions of a drl file contain an event type declaration for an existing class

mikedev9000
Mark, thank you for the response. I was able to reproduce this issue with 6.1CR1 and the latest code from the 6.1.x as of this morning.

I created a bug ticket for this issue and a pull request containing the unit test I wrote.
Ticket: https://issues.jboss.org/browse/DROOLS-560
Pull request: https://github.com/droolsjbpm/drools/pull/360
Reply | Threaded
Open this post in threaded view
|

Re: [rules-users] KieContainer#updateToVersion fails when both versions of a drl file contain an event type declaration for an existing class

Mario Fusco
Hi Mike,

I merged your test case and fixed the bug with this commit https://github.com/droolsjbpm/drools/commit/283ba1d94

Thanks a lot for having reported this problem,
Mario