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
<mailto: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>
<mailto: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> <mailto: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>
<mailto: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>
<mailto: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 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
