Am 16.04.2011 um 22:05 schrieb rules-dev-requ...@lists.jboss.org: > Send rules-dev mailing list submissions to > rules-dev@lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/rules-dev > or, via email, send a message with subject or body 'help' to > rules-dev-requ...@lists.jboss.org > > You can reach the person managing the list at > rules-dev-ow...@lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rules-dev digest..." > > > Today's Topics: > > 1. Re: Prolog Style Backward Chaining - First Cut (Michael Anstis) > 2. Re: Prolog Style Backward Chaining - First Cut (Mauricio Salatino) > 3. Re: Classpath Resources and Classloaders using cache > (Pablo Nussembaum) > 4. Re: Classpath Resources and Classloaders using cache > (Mauricio Salatino) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 16 Apr 2011 17:56:41 +0100 > From: Michael Anstis <michael.ans...@gmail.com> > Subject: Re: [rules-dev] Prolog Style Backward Chaining - First Cut > To: Rules Dev List <rules-dev@lists.jboss.org> > Message-ID: <banlktimmnceb3fj_8jylng+0_zkazt6...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Stilton good is favourite mine. > > The force is strong in this one. > > sent on the move > > On 16 Apr 2011 16:48, "Mark Proctor" <mproc...@codehaus.org> wrote: >> I have the basics to backward chaining working now, using both named and >> positional arguments and mix of both. Mixed positional/named syntax is >> based conceptually on the RuleML proposal for POSL: >> http://ruleml.org/submission/ruleml-shortation.html >> >> POSL provides a bridge between the positional terms, often used in >> Prolog, and "slotted" names used in OO languages. POSL allows the best >> of both worlds. >> >> I'm building out the tests, which should illustrate the behaviour and >> syntax here: >> > https://github.com/droolsjbpm/drools/tree/master/drools-compiler/src/test/java/org/drools/integrationtests/BackwardChainingTest.java >> >> Still lots to do to improve the over all syntax and consistency across >> patterns. The last test is a geneology style test which is probably more >> intesting to people. There is still an issue here when using eval. I >> currently use "new Variable" to indicate an unbound unification >> variable, the problem is that evals and other things generate code >> expecting the original object type, say "String" and this results a cast >> error (see sibling rule). I want to avoid an explicit instanceof check >> for unwrapping and will be working on that over the weekend. >> >> There is enough there now to give people an idea of what it looks like. >> I'll try and put together a "roadmap" for BC, along with more details of >> the syntax next week once it all comes together. >> >> If anyone wants to help on this, you know where to fine me :) >> irc.codehaus.org #drools >> >> Mark >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/rules-dev/attachments/20110416/9f0d4c0b/attachment-0001.html > > > ------------------------------ > > Message: 2 > Date: Sat, 16 Apr 2011 15:40:03 -0300 > From: Mauricio Salatino <sala...@gmail.com> > Subject: Re: [rules-dev] Prolog Style Backward Chaining - First Cut > To: Rules Dev List <rules-dev@lists.jboss.org> > Message-ID: <BANLkTinV+Ys+WUQO1=DSyE0UiY+e=WJi=w...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I will take a look at the test and try to think about something to include > in the emergency service app. > If you think about an use for BC in my app I can easily add it beacuse I'm > using the snapshots. > During the week I will ping you if I have an idea. > Greetings. > > PS: michael I will ping you too to see if you can help me with some DTables > :) > > On Sat, Apr 16, 2011 at 1:56 PM, Michael Anstis > <michael.ans...@gmail.com>wrote: > >> Stilton good is favourite mine. >> >> The force is strong in this one. >> >> sent on the move >> >> On 16 Apr 2011 16:48, "Mark Proctor" <mproc...@codehaus.org> wrote: >>> I have the basics to backward chaining working now, using both named and >>> positional arguments and mix of both. Mixed positional/named syntax is >>> based conceptually on the RuleML proposal for POSL: >>> http://ruleml.org/submission/ruleml-shortation.html >>> >>> POSL provides a bridge between the positional terms, often used in >>> Prolog, and "slotted" names used in OO languages. POSL allows the best >>> of both worlds. >>> >>> I'm building out the tests, which should illustrate the behaviour and >>> syntax here: >>> >> https://github.com/droolsjbpm/drools/tree/master/drools-compiler/src/test/java/org/drools/integrationtests/BackwardChainingTest.java >>> >>> Still lots to do to improve the over all syntax and consistency across >>> patterns. The last test is a geneology style test which is probably more >>> intesting to people. There is still an issue here when using eval. I >>> currently use "new Variable" to indicate an unbound unification >>> variable, the problem is that evals and other things generate code >>> expecting the original object type, say "String" and this results a cast >>> error (see sibling rule). I want to avoid an explicit instanceof check >>> for unwrapping and will be working on that over the weekend. >>> >>> There is enough there now to give people an idea of what it looks like. >>> I'll try and put together a "roadmap" for BC, along with more details of >>> the syntax next week once it all comes together. >>> >>> If anyone wants to help on this, you know where to fine me :) >>> irc.codehaus.org #drools >>> >>> Mark >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > > -- > - CTO @ http://www.plugtree.com > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/rules-dev/attachments/20110416/11a0a611/attachment-0001.html > > > ------------------------------ > > Message: 3 > Date: Sat, 16 Apr 2011 16:24:52 -0300 > From: Pablo Nussembaum <bau...@gmail.com> > Subject: Re: [rules-dev] Classpath Resources and Classloaders using > cache > To: Rules Dev List <rules-dev@lists.jboss.org> > Message-ID: <4da9ed04.3080...@gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Esteban, > You can assume that a resource that was obtained from the classpath exists in > your filesystem, for instance it can be a file inside a jar or war that are > not exploded. In other words you can't always > convert an URL to "file://". > > -- > Bauna > > On 04/15/2011 08:52 AM, Esteban Aliverti wrote: >> Hi Guys, >> >> I want to discuss a problem I have found when using the combination of >> knowledge agent + classpathResources. >> I will try to describe what am I doing first to give you some context. >> I'm deploying drools-camel-server in a Tomcat 7 container. Inside the >> WEB-INF/classes directory I have some DRL files that I want to use. >> My knowledge-services.xml file declares the following kagent: >> >> <drools:kagent id="kagent1" kbase="kbase1" new-instance="false"> >> <drools:resources> >> <drools:resource type="DRL" source="*classpath*:simple.drl"/> >> ... >> </drools:resources> >> </drools:kagent> >> >> When spring parses this configuration file it creates a KnowledgeAgent >> instance with a ChangeSet containing all the listed resources. >> The next step is to start ResourceChangeNotifierService and >> ResourceChangeScannerService. >> So far so good. >> >> The problem: >> The problem I'm having is not directly related to drools, but I think it is >> quite easy to provide a solution for the people that is in my same situation. >> >> ClassPathResource is the class that represents a resource defined as >> "*classpath:"* >> >> This class has 2 important methods: >> >> public long getLastModified(){ >> return this.classLoader.getResource( this.path >> ).openConnection().getLastModified(); >> } >> >> public InputStream getInputStream(){ >> return this.classLoader.getResourceAsStream( this.path ); >> } >> >> >> The first method is used by ResourceChangeScannerService to check whether >> the resource has changed or not. It works fine. When the resource in the >> filesystem changes, the scanner detects the change >> without any problem. >> The scanner ends up notifying the kagent about the change, and the kagent >> passes the Resource to an instance of KnowledgeBuilder. >> An here is when things fail. >> The kbuilder uses the second method of ClassPathResource (getInputStream()) >> to get the content of the resource. In the case of Tomcat (and probably some >> other environments), it seems that the >> classloader (Tomcat's classloader) is using a cache. So the InputStream >> returned doesn't reflect the current state of the resource. >> Long story short: the agent is notified about a change in the resource, but >> the change is never applied to the kbase because the kbuilder is unable to >> get it :P >> >> Solutions: >> The first solution is not to use classpath resources :). You can use just >> url resources like http:// or file:/. But honestly, when you have your rules >> inside your webapp, it is much >> more comfortable and even manageable to avoid the use of real paths. >> >> What I was thinking about (I already have a working prototype) is to create >> a new Resource type for these cases. This resource type will let you define >> your resources present in your classpath as >> usually but it will translate them to URL Resource internally. >> So, in the example above: >> >> <drools:resource type="DRL" source="*URLClasspath*:simple.drl"/> >> >> is going to be translated (internally and in a transparent way) to something >> like: file:/usr/local/apache-tomcat-7/webapps/MyWebapp/WEB-INF/simple.drl. >> >> Opinions? >> >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> Esteban Aliverti >> - Developer @ http://www.plugtree.com <http://www.plugtree.com> >> - Blog @ http://ilesteban.wordpress.com >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/rules-dev/attachments/20110416/2cb7fc73/attachment-0001.html > > > ------------------------------ > > Message: 4 > Date: Sat, 16 Apr 2011 17:05:28 -0300 > From: Mauricio Salatino <sala...@gmail.com> > Subject: Re: [rules-dev] Classpath Resources and Classloaders using > cache > To: Rules Dev List <rules-dev@lists.jboss.org> > Message-ID: <BANLkTim99233G8=A8Ki=eydozgunhjs...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Can you? or Can't you? > > > On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <bau...@gmail.com> wrote: > >> Esteban, >> You can assume that a resource that was obtained from the classpath exists >> in your filesystem, for instance it can be a file inside a jar or war that >> are not exploded. In other words you can't always convert an URL to >> "file://". >> >> -- >> Bauna >> >> >> On 04/15/2011 08:52 AM, Esteban Aliverti wrote: >> >> Hi Guys, >> >> I want to discuss a problem I have found when using the combination of >> knowledge agent + classpathResources. >> I will try to describe what am I doing first to give you some context. >> I'm deploying drools-camel-server in a Tomcat 7 container. Inside the >> WEB-INF/classes directory I have some DRL files that I want to use. >> My knowledge-services.xml file declares the following kagent: >> >> <drools:kagent id="kagent1" kbase="kbase1" new-instance="false"> >> <drools:resources> >> <drools:resource type="DRL" source="*classpath*:simple.drl"/> >> ... >> </drools:resources> >> </drools:kagent> >> >> When spring parses this configuration file it creates a KnowledgeAgent >> instance with a ChangeSet containing all the listed resources. >> The next step is to start ResourceChangeNotifierService >> and ResourceChangeScannerService. >> So far so good. >> >> The problem: >> The problem I'm having is not directly related to drools, but I think it is >> quite easy to provide a solution for the people that is in my same >> situation. >> >> ClassPathResource is the class that represents a resource defined as "* >> classpath:"* >> >> This class has 2 important methods: >> >> public long getLastModified(){ >> return this.classLoader.getResource( this.path >> ).openConnection().getLastModified(); >> } >> >> public InputStream getInputStream(){ >> return this.classLoader.getResourceAsStream( this.path ); >> } >> >> >> The first method is used by ResourceChangeScannerService to check whether >> the resource has changed or not. It works fine. When the resource in the >> filesystem changes, the scanner detects the change without any problem. >> The scanner ends up notifying the kagent about the change, and the kagent >> passes the Resource to an instance of KnowledgeBuilder. >> An here is when things fail. >> The kbuilder uses the second method of ClassPathResource (getInputStream()) >> to get the content of the resource. In the case of Tomcat (and probably some >> other environments), it seems that the classloader (Tomcat's classloader) is >> using a cache. So the InputStream returned doesn't reflect the current state >> of the resource. >> Long story short: the agent is notified about a change in the resource, but >> the change is never applied to the kbase because the kbuilder is unable to >> get it :P >> >> Solutions: >> The first solution is not to use classpath resources :). You can use just >> url resources like http:// or file:/. But honestly, when you have your >> rules inside your webapp, it is much more comfortable and even manageable to >> avoid the use of real paths. >> >> What I was thinking about (I already have a working prototype) is to >> create a new Resource type for these cases. This resource type will let you >> define your resources present in your classpath as usually but it will >> translate them to URL Resource internally. >> So, in the example above: >> >> <drools:resource type="DRL" source="*URLClasspath*:simple.drl"/> >> >> is going to be translated (internally and in a transparent way) to >> something like: >> file:/usr/local/apache-tomcat-7/webapps/MyWebapp/WEB-INF/simple.drl. >> >> Opinions? >> >> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> >> Esteban Aliverti >> - Developer @ http://www.plugtree.com >> - Blog @ http://ilesteban.wordpress.com >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > > -- > - CTO @ http://www.plugtree.com > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/rules-dev/attachments/20110416/ca5e7889/attachment.html > > > ------------------------------ > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > > End of rules-dev Digest, Vol 52, Issue 25 > ***************************************** >
Dr. Gernot Starke --- Willi-Lauf Allee 43, D-50858 Köln g...@gernotstarke.de, +49 177 - 728 2570 http://www.gernotstarke.de E-POSTBRIEF: gernot.sta...@epost.de _______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
