I don't see where it can fail. As long as we can make references to reosurces in the file system and resources in a jar, i think is enough. The idea of this new resource is to use it when you have the caching problem I described. If you don't have it, then you can use the old ClassPathResource (that by the way, converts the path to URL to get the last time the resource was modified :P)
Best Regards, El abr 17, 2011 8:50 a.m., "Mauricio Salatino" <sala...@gmail.com> escribió: > 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 <mproc...@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" <bau...@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 <sala...@gmail.com <mailto: >> sala...@gmail.com>> wrote: >> >>> >> >>> Can you? or Can't you? >> >>> >> >>> >> >>> >> >>> On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <bau...@gmail.com <mailto: >> 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 <http://www.plugtree.com> >> >>>> - Blog @ http://ilesteban.wordpress.com >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> rules-dev mailing list >> >>>> 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@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:// 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 -
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
