<p>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. <br>
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)</p>
<p>Best Regards,<br>
</p>
<div class="gmail_quote">El abr 17, 2011 8:50 a.m., "Mauricio Salatino" <<a href="mailto:salaboy@gmail.com">salaboy@gmail.com</a>> escribió:<br type="attribution">> totally.., we know that.. but it's like there will be always a situation<br>
> where that method will fail..<br>> I think that we can made the assumption for now and then try to find those<br>> missing bits.<br>> <br>> <br>> On Sat, Apr 16, 2011 at 11:11 PM, Mark Proctor <<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>>wrote:<br>
> <br>>> On 17/04/2011 02:31, Esteban Aliverti wrote:<br>>><br>>> Thanks pablo (aka baunax)!<br>>> I agree that resource -> file: is not always possible. But what about<br>>> resource -> URL? After all, i'm converting resources to URLs.<br>
>><br>>> The URL will have a pointer to the file inside of the jar.<br>>> <a href="http://www.exampledepot.com/egs/java.net/JarUrl.html">http://www.exampledepot.com/egs/java.net/JarUrl.html</a><br>>><br>
>> Mark<br>>><br>>> Best regards,<br>>> El abr 16, 2011 5:18 p.m., "Pablo Nussembaum" <<a href="mailto:baunax@gmail.com">baunax@gmail.com</a>><br>>> escribió:<br>>> > Sorry "IF I *wasn't* clear" :-P<br>
>> ><br>>> > On 04/16/2011 05:11 PM, Pablo Nussembaum wrote:<br>>> >> Sorry if I was clear. The problem when you do: ClassLoader.getResource(<br>>> "resource.path" ) is the the resource can be inside a war the in<br>
>> WEB-INF/classes and the war could be NOT exploded in<br>>> >> container that's is deployed, so the translation to something like<br>>> file:// is NOT reliable.<br>>> >><br>>> >> On 04/16/2011 05:05 PM, Mauricio Salatino wrote:<br>
>> >>> I'm still thinking about that mapping and those assumptions<br>>> >>><br>>> >>> On Sat, Apr 16, 2011 at 5:05 PM, Mauricio Salatino <<a href="mailto:salaboy@gmail.com">salaboy@gmail.com</a><mailto:<br>
>> <a href="mailto:salaboy@gmail.com">salaboy@gmail.com</a>>> wrote:<br>>> >>><br>>> >>> Can you? or Can't you?<br>>> >>><br>>> >>><br>>> >>><br>
>> >>> On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <<a href="mailto:baunax@gmail.com">baunax@gmail.com</a><mailto:<br>>> <a href="mailto:baunax@gmail.com">baunax@gmail.com</a>>> wrote:<br>
>> >>><br>>> >>> Esteban,<br>>> >>> You can assume that a resource that was obtained from the classpath<br>>> exists in your filesystem, for instance it can be a file inside a jar or war<br>
>> that are not exploded. In other words you<br>>> >>> can't always convert an URL to "file://".<br>>> >>><br>>> >>> --<br>>> >>> Bauna<br>>> >>><br>
>> >>><br>>> >>> On 04/15/2011 08:52 AM, Esteban Aliverti wrote:<br>>> >>>> Hi Guys,<br>>> >>>><br>>> >>>> I want to discuss a problem I have found when using the combination of<br>
>> knowledge agent + classpathResources.<br>>> >>>> I will try to describe what am I doing first to give you some context.<br>>><br>>> >>>> I'm deploying drools-camel-server in a Tomcat 7 container. Inside the<br>
>> WEB-INF/classes directory I have some DRL files that I want to use.<br>>> >>>> My knowledge-services.xml file declares the following kagent:<br>>> >>>><br>>> >>>> <drools:kagent id="kagent1" kbase="kbase1" new-instance="false"><br>
>> >>>> <drools:resources><br>>> >>>> <drools:resource type="DRL" source="*classpath*:simple.drl"/><br>>> >>>> ...<br>>> >>>> </drools:resources><br>
>> >>>> </drools:kagent><br>>> >>>><br>>> >>>> When spring parses this configuration file it creates a KnowledgeAgent<br>>> instance with a ChangeSet containing all the listed resources.<br>
>> >>>> The next step is to start ResourceChangeNotifierService and<br>>> ResourceChangeScannerService.<br>>> >>>> So far so good.<br>>> >>>><br>>> >>>> The problem:<br>
>> >>>> The problem I'm having is not directly related to drools, but I think<br>>> it is quite easy to provide a solution for the people that is in my same<br>>> situation.<br>>> >>>><br>
>> >>>> ClassPathResource is the class that represents a resource defined as<br>>> "*classpath:"*<br>>> >>>><br>>> >>>> This class has 2 important methods:<br>
>> >>>><br>>> >>>> public long getLastModified(){<br>>> >>>> return this.classLoader.getResource( this.path<br>>> ).openConnection().getLastModified();<br>>> >>>> }<br>
>> >>>><br>>> >>>> public InputStream getInputStream(){<br>>> >>>> return this.classLoader.getResourceAsStream( this.path );<br>>> >>>> }<br>>> >>>><br>
>> >>>><br>>> >>>> The first method is used by ResourceChangeScannerService to check<br>>> whether the resource has changed or not. It works fine. When the resource in<br>>> the filesystem changes, the scanner detects<br>
>> >>>> the change without any problem.<br>>> >>>> The scanner ends up notifying the kagent about the change, and the<br>>> kagent passes the Resource to an instance of KnowledgeBuilder.<br>
>> >>>> An here is when things fail.<br>>> >>>> The kbuilder uses the second method of ClassPathResource<br>>> (getInputStream()) to get the content of the resource. In the case of Tomcat<br>
>> (and probably some other environments), it seems that<br>>> >>>> the classloader (Tomcat's classloader) is using a cache. So the<br>>> InputStream returned doesn't reflect the current state of the resource.<br>
>> >>>> Long story short: the agent is notified about a change in the<br>>> resource, but the change is never applied to the kbase because the kbuilder<br>>> is unable to get it :P<br>>> >>>><br>
>> >>>> Solutions:<br>>> >>>> The first solution is not to use classpath resources :). You can use<br>>> just url resources like http:// or file:/. But honestly, when you have<br>
>> your rules inside your webapp, it is much<br>>> >>>> more comfortable and even manageable to avoid the use of real paths.<br>>> >>>><br>>> >>>> What I was thinking about (I already have a working prototype) is to<br>
>> create a new Resource type for these cases. This resource type will let you<br>>> define your resources present in your<br>>> >>>> classpath as usually but it will translate them to URL Resource<br>
>> internally.<br>>> >>>> So, in the example above:<br>>> >>>><br>>> >>>> <drools:resource type="DRL" source="*URLClasspath*:simple.drl"/><br>
>> >>>><br>>> >>>> is going to be translated (internally and in a transparent way) to<br>>> something like:<br>>> file:/usr/local/apache-tomcat-7/webapps/MyWebapp/WEB-INF/simple.drl.<br>
>> >>>><br>>> >>>> Opinions?<br>>> >>>><br>>> >>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br>>> >>>><br>>> >>>> Esteban Aliverti<br>
>> >>>> - Developer @ <a href="http://www.plugtree.com">http://www.plugtree.com</a> <<a href="http://www.plugtree.com">http://www.plugtree.com</a>><br>>> >>>> - Blog @ <a href="http://ilesteban.wordpress.com">http://ilesteban.wordpress.com</a><br>
>> >>>><br>>> >>>><br>>> >>>> _______________________________________________<br>>> >>>> rules-dev mailing list<br>>> >>>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <mailto:<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>>> >>><br>>> >>> _______________________________________________<br>
>> >>> rules-dev mailing list<br>>> >>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a> <mailto:<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>><br>
>> >>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>>> >>><br>>> >>><br>>> >>><br>>> >>><br>
>> >>> --<br>>> >>> - CTO @ <a href="http://www.plugtree.com">http://www.plugtree.com</a><br>>> >>> - MyJourney @ <a href="http://salaboy.wordpress.com">http://salaboy.wordpress.com</a><br>
>> >>> - Co-Founder @ <a href="http://www.jbug.com.ar">http://www.jbug.com.ar</a><br>>> >>><br>>> >>> - Salatino "Salaboy" Mauricio -<br>>> >>><br>>> >>><br>
>> >>><br>>> >>><br>>> >>> --<br>>> >>> - CTO @ <a href="http://www.plugtree.com">http://www.plugtree.com</a><br>>> >>> - MyJourney @ <a href="http://salaboy.wordpress.com">http://salaboy.wordpress.com</a><br>
>> >>> - Co-Founder @ <a href="http://www.jbug.com.ar">http://www.jbug.com.ar</a><br>>> >>><br>>> >>> - Salatino "Salaboy" Mauricio -<br>>><br>>><br>>> _______________________________________________<br>
>> rules-dev mailing listrules-dev@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/rules-dev">lists.jboss.org/mailman/listinfo/rules-dev</a><br>>><br>>><br>>><br>>> _______________________________________________<br>
>> rules-dev mailing list<br>>> <a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
>><br>>><br>> <br>> <br>> -- <br>> - CTO @ <a href="http://www.plugtree.com">http://www.plugtree.com</a><br>> - MyJourney @ <a href="http://salaboy.wordpress.com">http://salaboy.wordpress.com</a><br>
> - Co-Founder @ <a href="http://www.jbug.com.ar">http://www.jbug.com.ar</a><br>> <br>> - Salatino "Salaboy" Mauricio -<br></div>