[rules-dev] unsubscribe
Gernot Starke
gs at gernotstarke.de
Sat Apr 16 16:14:59 EDT 2011
Am 16.04.2011 um 22:05 schrieb rules-dev-request at lists.jboss.org:
> Send rules-dev mailing list submissions to
> rules-dev at 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-request at lists.jboss.org
>
> You can reach the person managing the list at
> rules-dev-owner at 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.anstis at gmail.com>
> Subject: Re: [rules-dev] Prolog Style Backward Chaining - First Cut
> To: Rules Dev List <rules-dev at lists.jboss.org>
> Message-ID: <BANLkTimmncEb3fJ_8jyLng+0_ZKAZT6_0A at 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" <mproctor at 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 at 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 <salaboy at gmail.com>
> Subject: Re: [rules-dev] Prolog Style Backward Chaining - First Cut
> To: Rules Dev List <rules-dev at lists.jboss.org>
> Message-ID: <BANLkTinV+Ys+WUQO1=DSyE0UiY+e=WJi=w at 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.anstis at 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" <mproctor at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at 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 <baunax at gmail.com>
> Subject: Re: [rules-dev] Classpath Resources and Classloaders using
> cache
> To: Rules Dev List <rules-dev at lists.jboss.org>
> Message-ID: <4DA9ED04.3080004 at 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 at 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 <salaboy at gmail.com>
> Subject: Re: [rules-dev] Classpath Resources and Classloaders using
> cache
> To: Rules Dev List <rules-dev at lists.jboss.org>
> Message-ID: <BANLkTim99233G8=A8Ki=EYdOZgUNhjSoOg at 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 <baunax at 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at 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 at 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
gs at gernotstarke.de,
+49 177 - 728 2570
http://www.gernotstarke.de
E-POSTBRIEF: gernot.starke at epost.de
More information about the rules-dev
mailing list