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(a)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(a)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(a)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(a)gmail.com
<mailto:
> salaboy(a)gmail.com>> wrote:
> >>>
> >>> Can you? or Can't you?
> >>>
> >>>
> >>>
> >>> On Sat, Apr 16, 2011 at 4:24 PM, Pablo Nussembaum <baunax(a)gmail.com
<mailto:
> baunax(a)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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
> >>>
> >>> _______________________________________________
> >>> rules-dev mailing list
> >>> rules-dev(a)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(a)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 -