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.
Thanks! Best Regards, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Esteban Aliverti - Developer @ http://www.plugtree.com - Blog @ http://ilesteban.wordpress.com On Fri, Apr 15, 2011 at 6:45 PM, Michael Anstis <michael.ans...@gmail.com>wrote: > 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.alive...@gmail.com> > 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.s...@gmail.com>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@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/rules-dev > >> > >> > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
