<html><body><div>Hi Wolfgang,</div><div><br></div><div>Thanks for that pointer. I'm still seeing errors when I use the import, but it's working when I call CloneMessage.cloneMessage. Which is good enough for me. :)</div><div><br></div><div>In case you're curious (or if anyone else is), I have knocked up a test project in github:</div><div style="padding-left: 24px; "><a href="https://github.com/gratiartis/scattercode-drools-scenarios">https://github.com/gratiartis/scattercode-drools-scenarios</a></div><div><br></div><div>... although you do need Maven installed to run it. Some folks hate that, but I'm a fan.</div><div><br></div><div>The 2 test cases I have been evaluating are here:</div><div><a href="https://github.com/gratiartis/scattercode-drools-scenarios/tree/master/src/test/java/uk/co/scattercode/drools/scenarios/functionimport">https://github.com/gratiartis/scattercode-drools-scenarios/tree/master/src/test/java/uk/co/scattercode/drools/scenarios/functionimport</a>
</div><div><br></div><div>Hopefully having that set up should make it quicker for me to demo such issues in the future.</div><div><br></div><div>Many thanks for the assistance.</div><div><br></div><div>Steve</div><div><br><br>On Jun 19, 2012, at 02:38 PM, Wolfgang Laun <wolfgang.laun@gmail.com> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch">In 5.4.0 (and 5.3.0) using an<br> import function x.y.CloneMessage.cloneMessage<br> lets me compile the MVEL version even with separate files all into the<br> same package (as in your post). Without this import, using<br> CloneMessage.cloneMessage(...)<br> works for me, also both versions.<br> <br> HTH<br> -W<br> <br> <br> On 19/06/2012, Stephen Masters <<a href="mailto:stephen.masters@me.com" data-mce-href="mailto:stephen.masters@me.com">stephen.masters@me.com</a>> wrote:<br> > My understanding from the docs is that the DRL functions are converted into<br> > helper classes, which can be imported with "import function<br> > mypackage.CloneMessage.cloneMessage", although it's not clear what that<br> > 'class name' (?) in the middle refers to. Maybe the generated helper class?<br> > However, if the function is in your current package the import is<br> > automatically derived for you. Hence no import statements in my tests. Which<br> > is nice. :)<br> ><br> > I just tried combining them in a single file, and it still fails for the<br> > same reason. I'm still on 5.3.1 at the moment, so I think this might be a<br> > new item for my list of reasons to roll up my sleeves and upgrade.<br> ><br> > Thanks for taking a look,<br> ><br> > Steve<br> ><br> ><br> > On Jun 19, 2012, at 01:42 PM, Wolfgang Laun <<a href="mailto:wolfgang.laun@gmail.com" data-mce-href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>> wrote:<br> ><br> > It works (5.4.0) with both, Java and MVEL, if all is in the same DRL file.<br> ><br> > I'm somewhat surprised that "import" should work for DRL functions,<br> > but I may have missed some development. But your snippets don't show a<br> > DRL import statement?<br> ><br> > -W<br> ><br> ><br> > On 19/06/2012, Stephen Masters <<a href="mailto:stephen.masters@me.com" data-mce-href="mailto:stephen.masters@me.com">stephen.masters@me.com</a>> wrote:<br> >> Okay Wolfgang ... you asked for it. Here's a version which takes it pretty<br> >> much to the minimum.<br> >><br> >> The error I see is "Unable to resolve method using strict-mode:<br> >> mypackage.CloneMessage.cloneMessage(mypackage.Message)"<br> >><br> >> However, the error is only seen when I use mvel dialect. The working Java<br> >> dialect rule is also included below.<br> >><br> >> Note that when I re-wrote the example function to take a common type such<br> >> as<br> >> String as argument, then the mvel version worked. It's when the argument<br> >> is<br> >> a declared type that it fails.<br> >><br> >> Thanks for taking a look,<br> >><br> >> Steve<br> >><br> >><br> >><br> >> file - MessageFact.drl<br> >><br> >> package mypackage<br> >><br> >> declare Message<br> >> Text: String<br> >> end<br> >><br> >><br> >><br> >> file - CloneMessage.drl<br> >><br> >> package mypackage<br> >><br> >> function Message cloneMessage(Message originalMessage) {<br> >><br> >> Message newMessage = new Message();<br> >> newMessage.setText(originalMessage.getText());<br> >> return newMessage;<br> >><br> >> }<br> >><br> >><br> >><br> >> file - SayHelloRuleJava.drl<br> >><br> >> package mypackage<br> >><br> >> rule "Say hello"<br> >> dialect "java"<br> >> lock-on-active true<br> >> when<br> >> # Always<br> >> then<br> >> Message originalMessage = new Message();<br> >> originalMessage.setText("Hello, World!");<br> >><br> >> Message clonedMessage = cloneMessage(originalMessage);<br> >><br> >> insert(clonedMessage);<br> >> end<br> >><br> >><br> >><br> >> file - SayHelloRuleMvel.drl<br> >><br> >> package mypackage<br> >><br> >> rule "Say hello"<br> >> dialect "mvel"<br> >> lock-on-active true<br> >> when<br> >> # Always<br> >> then<br> >> Message originalMessage = new Message();<br> >> originalMessage.Text = "Hello, World!";<br> >><br> >> Message clonedMessage = cloneMessage(originalMessage);<br> >><br> >> insert(clonedMessage);<br> >> end<br> >><br> >><br> >><br> >> On Jun 19, 2012, at 12:27 PM, Wolfgang Laun <<a href="mailto:wolfgang.laun@gmail.com" data-mce-href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>><br> >> wrote:<br> >><br> >> Can you please provide an example where and how you import and use a<br> >> DRL function so that it works/doesn't work with MVEL/Java?<br> >><br> >> -W<br> >><br> >><br> >> On 19/06/2012, Stephen Masters <<a href="mailto:stephen.masters@me.com" data-mce-href="mailto:stephen.masters@me.com">stephen.masters@me.com</a>> wrote:<br> >>> Hi folks,<br> >>><br> >>> Is it possible to refer to DRL functions from a DRL when the dialect is<br> >>> mvel?<br> >>><br> >>> I have been working on unit tests for a rule that were consistently<br> >>> failing<br> >>> due to not being able to find the function that should be imported.<br> >>> Having<br> >>> tried various formats (the documentation is rather unhelpful here) for<br> >>> the<br> >>> import, I thought I'd see what happened if I just switched to the Java<br> >>> dialect. Suddenly it worked without even needing an import statement.<br> >>><br> >>> Unfortunately, this forces me to switch from the neat ...<br> >>> newFact.Property = otherFact.Property<br> >>> ... to the rather ugly Java-style<br> >>> newFact.setProperty(otherFact.getProperty())<br> >>><br> >>> So I would quite like to know if there is an undocumented (or<br> >>> well-hidden-documented) mechanism for using functions when in mvel<br> >>> dialect.<br> >>> Or am I stuck with switching to Java?<br> >>><br> >>> Thanks in advance for any pointers anybody can provide,<br> >>><br> >>> Steve<br> >> _______________________________________________<br> >> rules-users mailing list<br> >> <a href="mailto:rules-users@lists.jboss.org" data-mce-href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br> >> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" data-mce-href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a><br> >><br> > _______________________________________________<br> > rules-users mailing list<br> > <a href="mailto:rules-users@lists.jboss.org" data-mce-href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br> > <a href="https://lists.jboss.org/mailman/listinfo/rules-users" data-mce-href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a><br> ><br> _______________________________________________<br> rules-users mailing list<br> <a href="mailto:rules-users@lists.jboss.org" data-mce-href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" data-mce-href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a><br></div></div></blockquote></div></body></html>