Mark, I would be willing to make the changes, but do you think there are bigger fish to fry?
dave On Wed, Oct 15, 2008 at 4:49 PM, Mark Proctor <[EMAIL PROTECTED]> wrote: > The globals are global to the consequence, where we inject them for the > user. For the function we expect the user to pass those injected globals as > arguments, i'm not convinced that this is overly more painful that the > variables automatigically being there in the function. > > That said if someone was will doing to do the work, we woudl probably > accept the patch. But it would need to do the following. > 1) determine the used globals for the function > 2) add those parameters onto the end of the generated function. > 3) update any generated consequences, or functions for that matter, and add > in the globals to the paramters list. > > So basically a lot of data munging in the templates. > > Mark > Greg Barton wrote: > > How about a ThreadLocal? > > --- On Wed, 10/15/08, David Sinclair <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > wrote: > > > > From: David Sinclair <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > Subject: [rules-dev] Re: [rules-users] No globals in functions? > To: "Edson Tirelli" <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > Cc: "Mark Proctor" <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>, "Rules Dev List" > <[email protected]> <[email protected]> > Date: Wednesday, October 15, 2008, 12:53 PM > What about injecting the globals into the classes and doing > reflection to > invoke the method dynamically? That way we would only need > to change the > JavaFunctionBuilder to rewrite the calls to the globals? > For example > > function foo() { > global.bar(abx); > } > > gets re-written as > > function foo() { > method.invoke(global, [abx]); > } > > methods would be cached and such. Or do you guys not want > the reflection in > there? > > > On Wed, Oct 15, 2008 at 1:45 PM, Edson Tirelli<[EMAIL PROTECTED]> <[EMAIL > PROTECTED]> wrote: > > > > It may be invoked by a consequence, an eval, a > > > predicate, or a return > > > value constraint. > > If you fix it for the consequence in > > > JavaConsequenceBuilder, the others > > > will work the same. You will have to change the java.g > > > grammar as I > > > mentioned in my previousre e-mail to make it work. > > []s > Edson > > 2008/10/14 David Sinclair > > > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > Edson, > > > Changing the builder shouldn't be too much of > > > a problem. If I make the > > > changes you suggested, how does the global > > > actually get passed to the > > > method? For example if something defined a > > > function like > > > void function doX(int abc) { > ... > global.doY(bcd); > } > and I rewrite it to be > > void function doX(int abc, GlobalType global) { > ... > } > > Who is the invoker of the method? > > thanks > > dave > > > > On Mon, Oct 13, 2008 at 3:24 PM, Edson Tirelli > > > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: > > > Hi Dave, > > Excellent! > I will try to explain the current situation > > > and one possible solution, > > > but you may have better ideas. > > Functions in Drools are compiled as simple > > > static methods in a > > > generated java class. We use MVEL Templates to > > > generate the code of the > > > class and the static method. > > Take a look at JavaFunctionBuilder.java > > > class for the code generation > > > call and at javaFunction.mvel for the code > > > template. > > > Now, the problem with globals is that they > > > are scoped to sessions, not > > > rulebases, so you can not resolve them until > > > runtime. You can not for > > > instance, make them a static reference of the > > > generated class and set it at > > > rulebase compilation time. > > So, my suggestion would be to: > > 1. at compile time, use > > > JavaDialect.analyzeBlock() method to analyze and > > > find out what are the globals that are used by > > > the funcion method code. > > > 2. modify the code generation to add > > > parameters to that in the method > > > call. So, if "log" is a global and > > > if the function is declared like this: > > > function void someFunction( String param ) { > // ... code ... > log.something(...); > // ... code ... > } > > you detect the use of "log" and > > > add it as a parameter of the generated > > > method: > > ... > public static void someFunction( Logger log, > > > String Param ) { > > > ... > } > ... > > This way, at runtime we can inject the > > > parameter into the call. You > > > can look at JavaConsequenceBuilder.java and > > > javaInvokers.mvel to see how we > > > do kind-of the same thing for consequences. > > 3. Now the most interesting part. :) We use > > > an ANTLR grammar for parsing > > > Java code blocks. You need to change the > > > parser to rewrite any function call > > > the user is doing in his code to inject the > > > log parameter transparently. I > > > did the very same thing for modify blocks: > > modify( $something ) { > ... > } > > It is not hard once you get the hang of it. > > > It is a bit of "hand work" > > > though. Look at the > > > JavaConsequenceBuilder.fixModifyBlocks() for what I did. > > > Also, the ANTLR Java grammar is java.g. > > Let me know if you have questions or if you > > > have a better idea, and > > > welcome aboard! > > Cheers, > Edson > > > > 2008/10/13 David Sinclair > > > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > Hi Edson, > > > My name is dave sinclair. I started using > > > Drools in early August of this > > > year, but have a lot of experience with > > > rules engines. I have worked > > > primarily with ArtEntrprise and some with > > > PegaRules. I would love to help > > > with this project and thought that this > > > may be the area to jump in on. > > > I have the M2 code, and was reading it > > > over the weekend. Mostly the core > > > and some of the compilier. If you want to > > > point me in the right direction on > > > the global/functions I'd be happy to > > > have a look. > > > thanks > > dave > > > On Mon, Oct 13, 2008 at 9:59 AM, Bagwell, > > > Allen F <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>wrote: > > > Edson, > > Thanks for the tip. I figured I'd > > > need to use a workaround like this. > > > Unfortunately I'm under a series > > > of tight development and test > > > deadlines all the way into early > > > summer. Otherwise, I'd have a look. > > > Hopefully someone else out there can > > > assist. > > > Thanks, > -A > > ------------------------------ > *From:* > > > [EMAIL PROTECTED] [mailto: > > [EMAIL PROTECTED] > > > *On Behalf Of *Edson Tirelli > > > *Sent:* Friday, October 10, 2008 5:46 > > > AM > > > *To:* Rules Users List > *Subject:* Re: [rules-users] No > > > globals in functions? > > > Allen, > > There is a technical explanation > > > behind that and we never had the > > > time to find a way to overcome this > > > limitation. What you can do, although > > > not ideal, is to send the global as a > > > parameter: > > > funcion void foo( Logger log, String > > > cond ) > > > { > ... > } > > rule XYZ > when > then > foo( log, someString ); > end > > If you or anyone would like to help > > > improving this, let us know and > > > we can discuss ways into doing it. > > []s > Edson > > 2008/10/9 Bagwell, Allen F > > > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > There's probably an easy > > > explanation for this. I was wondering about > > > why functions inside of rule files > > > can't access globals? > > > For example, I have a log4j logger > > > that I pass into my rule files via > > > a global. The logger should never > > > be a part of working memory. It's just > > > there to capture valuable > > > feedback. > > > But I can't do this: > > global Logger log; > > function void foo(String cond) > { > if (cond == "error") > log.error("I saw an > > > error"); > > > } > > Because the compiler says that in > > > the function it can't resolve 'log'. > > > -A > > Allen F. Bagwell > e-mail: [EMAIL PROTECTED] > phone: 505/284-4517 > fax: 505/ 844-7886 > > There is no monument dedicated to > > > the memory of a committee. -- Lester > > > J. Pourciau > > > > > > > > _______________________________________________ > > > rules-users mailing [EMAIL PROTECTED] > > https://lists.jboss.org/mailman/listinfo/rules-users > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss, a division of Red Hat @ > > > www.jboss.com > > _______________________________________________ > > > rules-users mailing [EMAIL PROTECTED] > > https://lists.jboss.org/mailman/listinfo/rules-users > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss, a division of Red Hat @ www.jboss.com > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss, a division of Red Hat @ www.jboss.com > > _______________________________________________ > rules-dev mailing [EMAIL > PROTECTED]://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
