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
