can someone tell me, when to use java or mvel as dialect ? I've experienced that in some cases inside the drl editor using java gives me more context-help then using mvel but: what can I do with java and not with mvel and what advantages has mvel compared with java which dialect is more performant ? thx for infos from insiders ekke

BTW, when using Java, is there a way to save the .java files created by the compiler? I would like to understand the specific environment/scope in which consequences are compiled. Right now, if something goes wrong, the .java are deleted right away. I looked at PackageBuilderOptions, but didn't see anything there. - Godmar On 9/24/07, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > Java is more mature in tooling and implementation and is still currently > the default implementation and the recommended one if you are not sure. > MVEL will eventually become the default dialect when it matures, its > advantage is in the simpler language it provides, which helps make rules > easier to read and write. It can also operate in reflection mode, which > can really help for large rule based systems that have perm gen issues. > > Mark > ekke wrote: > >> can someone tell me, when to use java or mvel as dialect ? >> >> I've experienced that in some cases inside the drl editor using java >> gives me more context-help then using mvel >> >> but: what can I do with java and not with mvel >> and what advantages has mvel compared with java >> >> which dialect is more performant ? >> >> thx for infos from insiders >> >> ekke >> >> > _______________________________________________ > 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

Change and re-compile the drool engine code? If so, I vote for an enhancement request that let's drool dump the Java files.

On a separate note, how would I be able to pre-compile sets of rules - would this process involve calling builder.getPackage(), then serialize the resulting Package? Or would I need to serialize a partial rule base? Or either?

In other words, is the compilation done on "builder.addPackageFromDrl()", or done when "builder.getPackage()" is called, or is it done when "Rulebase.addPackage()" is called?

Thank you for your help. - Godmar On 9/24/07, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > There is no .java file, all compilation is in memory. you can, if you > change the code and re-compile by hand, dump the resulting template files. > > Mark > > Godmar Back wrote: > BTW, when using Java, is there a way to save the .java files created > by the compiler? I would like to understand the specific > environment/scope in which consequences are compiled. Right now, if > something goes wrong, the .java are deleted right away. I looked at > PackageBuilderOptions, but didn't see anything there. > > - Godmar > > On 9/24/07, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > > > Java is more mature in tooling and implementation and is still currently > the default implementation and the recommended one if you are not sure. > MVEL will eventually become the default dialect when it matures, its > advantage is in the simpler language it provides, which helps make rules > easier to read and write. It can also operate in reflection mode, which > can really help for large rule based systems that have perm gen issues. > > Mark > ekke wrote: > > > can someone tell me, when to use java or mvel as dialect ? > > I've experienced that in some cases inside the drl editor using java > gives me more context-help then using mvel > > but: what can I do with java and not with mvel > and what advantages has mvel compared with java > > which dialect is more performant ? > > thx for infos from insiders > > ekke > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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