Hi Michael, that is exactly what I think. Once your application is deployed, the URL should be static. The idea of what I'm trying to do is to maintain the definitions of your change-sets using classpath notation. Then, when the application loads the resources, it converts them to static URLs.<div>
<br></div><div>Thanks!</div><div><br></div><div>Best Regards, <div><br>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br><br>Esteban Aliverti<br>- Developer @ <a href="http://www.plugtree.com" target="_blank">http://www.plugtree.com </a><br>
- Blog @ <a href="http://ilesteban.wordpress.com" target="_blank">http://ilesteban.wordpress.com</a><br>
<br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 6:45 PM, Michael Anstis <span dir="ltr"><<a href="mailto:michael.anstis@gmail.com">michael.anstis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<p>Aren't the 'converted' Urls just transient? I.e. tied to a runtime installation? So what is the danger of platform specific conversion?</p>
<p>sent on the move</p>
<p></p><div><div></div><div class="h5">On 15 Apr 2011 22:40, "Esteban Aliverti" <<a href="mailto:esteban.aliverti@gmail.com" target="_blank">esteban.aliverti@gmail.com</a>> wrote:<br type="attribution">> Hi Geoffrey,<br>
> thanks for sharing your opinion!<br>
> <br>> When drools-spring creates the resource from the configuration file, it<br>> creates it passing the class' class loader:<br>> <br>> new ClassPathResource(path, ClassPathResource.class.getClassLoader() );<br>
> <br>> Internally, ClassPathResource is doing:<br>> <br>> this.classLoader = ClassLoaderUtil.getClassLoader( new ClassLoader[] {<br>> classLoader },null, false );<br>> <br>> So, a classloader is indeed supplied. AFAIK, the problem is that the<br>
> provided classloader is tomcat's classloader.<br>> <br>> I know it is dangerous to store native URLs instead of the classpath, but<br>> after all, after you deploy drools-server, each of the resources will have<br>
> an URL.<br>> If this is a problem, you can always use classpath resources. That is why I<br>> thought in a new Resource type and not in modify ClassPathResource class.<br>> <br>> I have created an issue for this:<br>
> <a href="https://issues.jboss.org/browse/JBRULES-2960" target="_blank">https://issues.jboss.org/browse/JBRULES-2960</a><br>> <br>> Thanks again for your time!<br>> <br>> Best Regards,<br>> <br>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br>
> <br>> Esteban Aliverti<br>> - Developer @ <a href="http://www.plugtree.com" target="_blank">http://www.plugtree.com</a><br>> - Blog @ <a href="http://ilesteban.wordpress.com" target="_blank">http://ilesteban.wordpress.com</a><br>
> <br>> <br>
> On Fri, Apr 15, 2011 at 9:38 AM, Geoffrey De Smet<br>> <<a href="mailto:ge0ffrey.spam@gmail.com" target="_blank">ge0ffrey.spam@gmail.com</a>>wrote:<br>> <br>>> The kbuilder uses the second method of ClassPathResource<br>
>> (getInputStream()) to get the content of the resource.<br>>><br>>><br>>> Shouldn't that also supply a ClassLoader or a Class (of which<br>>> Class.getClassLoader() is used)?<br>>><br>
>><br>>> This resource type will let you define your resources present in your<br>>> classpath as usually but it will translate them to URL Resource internally.<br>>><br>>> It's probably dangerous to store the native URL the concept of a classpath<br>
>> is designed to have a map of files "that are just there" and you don't need<br>>> to worry what's the OS-specific underlying details.<br>>> Instead, I believe, the classpath key (for example "simpler.drl") and the<br>
>> ClassLoader (for example MyApp.class.getClassLoader()) should be stored.<br>>><br>>> Op 15-04-11 13:52, Esteban Aliverti schreef:<br>>><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>>> 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<br>
>> and 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 it is<br>>> 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 whether<br>>> the resource has changed or not. It works fine. When the resource in the<br>
>> filesystem changes, the scanner detects the change without any problem.<br>>> The scanner ends up notifying the kagent about the change, and the kagent<br>>> passes the Resource to an instance of KnowledgeBuilder.<br>
>> An here is when things fail.<br>>> The kbuilder uses the second method of ClassPathResource (getInputStream())<br>>> to get the content of the resource. In the case of Tomcat (and probably some<br>>> other environments), it seems that the classloader (Tomcat's classloader) is<br>
>> using a cache. So the InputStream returned doesn't reflect the current state<br>>> of the resource.<br>>> Long story short: the agent is notified about a change in the resource, but<br>>> the change is never applied to the kbase because the kbuilder is unable to<br>
>> get it :P<br>>><br>>> Solutions:<br>>> The first solution is not to use classpath resources :). You can use just<br>>> url resources like http:// or file:/. But honestly, when you have your<br>
>> rules inside your webapp, it is much more comfortable and even manageable to<br>>> 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 classpath as usually but it will<br>>> translate them to URL Resource 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" target="_blank">http://www.plugtree.com</a><br>>> - Blog @ <a href="http://ilesteban.wordpress.com" target="_blank">http://ilesteban.wordpress.com</a><br>
>><br>
>><br>>> _______________________________________________<br></div></div>>> rules-dev mailing listrules-dev@lists.jboss.orghttps://<a href="http://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">lists.jboss.org/mailman/listinfo/rules-dev</a><div class="im">
<br>
>><br>>><br>>> --<br>>> With kind regards,<br>>> Geoffrey De Smet<br>>><br>>><br>>> _______________________________________________<br>>> rules-dev mailing list<br>>> <a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>>><br>>><br></div><p></p>
<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" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br></div></div>