[rules-dev] Classpath Resources and Classloaders using cache
Esteban Aliverti
esteban.aliverti at gmail.com
Sun Apr 17 09:16:16 EDT 2011
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" <salaboy at 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 <mproctor at 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" <baunax at 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 <salaboy at gmail.com
<mailto:
>> salaboy at gmail.com>> wrote:
>> >>>
>> >>> Can you? or Can't you?
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <baunax at gmail.com
<mailto:
>> baunax at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>>
>> >>> _______________________________________________
>> >>> rules-dev mailing list
>> >>> rules-dev at lists.jboss.org <mailto:rules-dev at 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 at lists.jboss.orghttps://
lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at 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 -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110417/434b295f/attachment-0001.html
More information about the rules-dev
mailing list