The kbuilder uses the second method of ClassPathResource (getInputStream()) to get the content of the resource. Shouldn't that also supply a ClassLoader or a Class (of which Class.getClassLoader() is used)? This resource type will let you define your resources present in your classpath as usually but it will translate them to URL Resource internally. It's probably dangerous to store the native URL the concept of a classpath is designed to have a map of files "that are just there" and you don't need to worry what's the OS-specific underlying details. Instead, I believe, the classpath key (for example "simpler.drl") and the ClassLoader (for example MyApp.class.getClassLoader()) should be stored. Op 15-04-11 13:52, Esteban Aliverti schreef: 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 listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Aren't the 'converted' Urls just transient? I.e. tied to a runtime installation? So what is the danger of platform specific conversion? sent on the move On 15 Apr 2011 22:40, "Esteban Aliverti" <esteban.aliverti(a)gmail.com&gt; wrote: > Hi Geoffrey, > thanks for sharing your opinion! > > When drools-spring creates the resource from the configuration file, it > creates it passing the class' class loader: > > new ClassPathResource(path, ClassPathResource.class.getClassLoader() ); > > Internally, ClassPathResource is doing: > > this.classLoader = ClassLoaderUtil.getClassLoader( new ClassLoader[] { > classLoader },null, false ); > > So, a classloader is indeed supplied. AFAIK, the problem is that the > provided classloader is tomcat's classloader. > > I know it is dangerous to store native URLs instead of the classpath, but > after all, after you deploy drools-server, each of the resources will have > an URL. > If this is a problem, you can always use classpath resources. That is why I > thought in a new Resource type and not in modify ClassPathResource class. > > I have created an issue for this: > https://issues.jboss.org/browse/JBRULES-2960 > > Thanks again for your time! > > Best Regards, > > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > > Esteban Aliverti > - Developer @ http://www.plugtree.com > - Blog @ http://ilesteban.wordpress.com > > > On Fri, Apr 15, 2011 at 9:38 AM, Geoffrey De Smet > <ge0ffrey.spam(a)gmail.com&gt;wrote: > >> The kbuilder uses the second method of ClassPathResource >> (getInputStream()) to get the content of the resource. >> >> >> Shouldn't that also supply a ClassLoader or a Class (of which >> Class.getClassLoader() is used)? >> >> >> This resource type will let you define your resources present in your >> classpath as usually but it will translate them to URL Resource internally. >> >> It's probably dangerous to store the native URL the concept of a classpath >> is designed to have a map of files "that are just there" and you don't need >> to worry what's the OS-specific underlying details. >> Instead, I believe, the classpath key (for example "simpler.drl") and the >> ClassLoader (for example MyApp.class.getClassLoader()) should be stored. >> >> Op 15-04-11 13:52, Esteban Aliverti schreef: >> >> 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 listrules-dev@lists.jboss.orghttps:// lists.jboss.org/mailman/listinfo/rules-dev >> >> >> -- >> With kind regards, >> Geoffrey De Smet >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

I'm still thinking about that mapping and those assumptions On Sat, Apr 16, 2011 at 5:05 PM, Mauricio Salatino <salaboy(a)gmail.com <mailto:salaboy@gmail.com>> wrote: Can you? or Can't you? On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <baunax(a)gmail.com <mailto:baunax@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 <http://www.plugtree.com> > - Blog @ http://ilesteban.wordpress.com > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto: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 - -- - CTO @ http://www.plugtree.com - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

Sorry if I was clear. The problem when you do: ClassLoader.getResource( "resource.path" ) is the the resource can be inside a war the in WEB-INF/classes and the war could be NOT exploded in container that's is deployed, so the translation to something like file:// is NOT reliable. On 04/16/2011 05:05 PM, Mauricio Salatino wrote: > I'm still thinking about that mapping and those assumptions > > On Sat, Apr 16, 2011 at 5:05 PM, Mauricio Salatino <salaboy(a)gmail.com <mailto:salaboy@gmail.com>> wrote: > > Can you? or Can't you? > > > > On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <baunax(a)gmail.com <mailto:baunax@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 <http://www.plugtree.com> >> - Blog @ http://ilesteban.wordpress.com >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto: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 - > > > > > -- > - CTO @ http://www.plugtree.com > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio -

Thanks pablo (aka baunax)! I agree that resource -> file: is not always possible. But what about resource -> URL? After all, i'm converting resources to URLs.

Best regards, El abr 16, 2011 5:18 p.m., "Pablo Nussembaum" <baunax(a)gmail.com <mailto:baunax@gmail.com>> escribió: > Sorry "IF I *wasn't* clear" :-P > > On 04/16/2011 05:11 PM, Pablo Nussembaum wrote: >> Sorry if I was clear. The problem when you do: ClassLoader.getResource( "resource.path" ) is the the resource can be inside a war the in WEB-INF/classes and the war could be NOT exploded in >> container that's is deployed, so the translation to something like file:// is NOT reliable. >> >> On 04/16/2011 05:05 PM, Mauricio Salatino wrote: >>> I'm still thinking about that mapping and those assumptions >>> >>> On Sat, Apr 16, 2011 at 5:05 PM, Mauricio Salatino <salaboy(a)gmail.com <mailto:salaboy@gmail.com> <mailto:salaboy@gmail.com <mailto:salaboy@gmail.com>>> wrote: >>> >>> Can you? or Can't you? >>> >>> >>> >>> On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <baunax(a)gmail.com <mailto:baunax@gmail.com> <mailto:baunax@gmail.com <mailto:baunax@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 <http://www.plugtree.com> >>>> - Blog @ http://ilesteban.wordpress.com >>>> >>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <mailto:rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <mailto:rules-dev@lists.jboss.org <mailto: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 - >>> >>> >>> >>> >>> -- >>> - CTO @ http://www.plugtree.com >>> - MyJourney @ http://salaboy.wordpress.com >>> - Co-Founder @ http://www.jbug.com.ar >>> >>> - Salatino "Salaboy" Mauricio - _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

totally.., we know that.. but it's like there will be always a situation where that method will fail.. I think that we can made the assumption for now and then try to find those missing bits. On Sat, Apr 16, 2011 at 11:11 PM, Mark Proctor <mproctor(a)codehaus.org wrote: > On 17/04/2011 02:31, Esteban Aliverti wrote: > > Thanks pablo (aka baunax)! > I agree that resource -> file: is not always possible. But what about > resource -> URL? After all, i'm converting resources to URLs. > > The URL will have a pointer to the file inside of the jar. > http://www.exampledepot.com/egs/java.net/JarUrl.html > > Mark > > Best regards, > El abr 16, 2011 5:18 p.m., "Pablo Nussembaum" <baunax(a)gmail.com&gt; > escribió: > > Sorry "IF I *wasn't* clear" :-P > > > > On 04/16/2011 05:11 PM, Pablo Nussembaum wrote: > >> Sorry if I was clear. The problem when you do:

> "resource.path" ) is the the resource can be inside a war the in > WEB-INF/classes and the war could be NOT exploded in > >> container that's is deployed, so the translation to something like > file:// is NOT reliable. > >> > >> On 04/16/2011 05:05 PM, Mauricio Salatino wrote: > >>> I'm still thinking about that mapping and those assumptions > >>> > >>> On Sat, Apr 16, 2011 at 5:05 PM, Mauricio Salatino <salaboy(a)gmail.com

> salaboy(a)gmail.com&gt;&gt; wrote: > >>> > >>> Can you? or Can't you? > >>> > >>> > >>> > >>> On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <baunax(a)gmail.com

> baunax(a)gmail.com&gt;&gt; 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

> 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

> knowledge agent + classpathResources. > >>>> I will try to describe what am I doing first to give you some

> > >>>> I'm deploying drools-camel-server in a Tomcat 7 container. Inside

> 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

> 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

> 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

> 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

> (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

> 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

> 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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > >>> > >>> _______________________________________________ > >>> rules-dev mailing list > >>> rules-dev(a)lists.jboss.org <mailto: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 - > >>> > >>> > >>> > >>> > >>> -- > >>> - CTO @ http://www.plugtree.com > >>> - MyJourney @ http://salaboy.wordpress.com > >>> - Co-Founder @ http://www.jbug.com.ar > >>> > >>> - Salatino "Salaboy" Mauricio - > > > _______________________________________________ > rules-dev mailing listrules-dev@lists.jboss.orghttps://

> > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)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 -