Re: ClasspathResourceLoader comments

[Will Glass-Husain]

Good.  I like the idea of a fallback myself.  (Can't find the resource - do
it the old way).
Regarding Geir's comment of what might break.  Would there be a situation in
which a false positive is an issue?  In other words, is there a case where
you want the resource loader to fail?  (Except it doesn't because the
resource exists at the primordial class loader level).  Seems a strange case
to me.
Also, any comments on the caching issue?  Specifically, we could add caching
for limited cases by translating a class to a filename (when applicable).
As I said in my email, I'm uncomfortable with this but wanted to raise the
possibility nonetheless.  Regardless, we'll need to add to the
ClasspathResourceLoader docs that cache reloading doesn't work.  (I found
this personally confusing when I first used it).
Best,
WILL
----- Original Message ----- 
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[EMAIL PROTECTED]>
Cc: "Will Glass-Husain" <[EMAIL PROTECTED]>
Sent: Monday, November 29, 2004 1:18 PM
Subject: Re: ClasspathResourceLoader comments


On Nov 29, 2004, at 12:27 PM, Mike Heath wrote:
(6)  Here's a problem.  Any use of this ClasspathResourceLoader within a
custom ant task (such as Texen) breaks.  In the "ant test" suite, ant
test-texen-classpath can't find the file.  Apparently, with ant 1.5 the
method call returns the primordial class loader (should be ok).  With
ant
1.6 (which I use), you see the class loader for the ant jar files.  Does
this mean that we should mark this bug DONT_FIX?  It'd be nice to see a
consensus rather than letting this bug hang open.
It is important to note that the classloader problem exists for many
container based architectures.  I discovered the problem using Apache
James (which is a Phoenix based application) so it is not just a
Tomcat, servlet or J2EE problem.
Compatibility with Ant is certainly import but I feel strongly that
marking this bug as "DONT_FIX" would be ignoring the fact that the
ClasspathResourceLoader *is* broken as it stands now.
To maintain compatibility with Ant, I would propose the following:
Change:
 ClassLoader classLoader = this.getClass().getClassLoader();
 result= classLoader.getResourceAsStream( name );
To:
 ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
 if (classLoader == null) {
  classLoader = this.getClass().getClassLoader();
  result= classLoader.getResourceAsStream( name );
 } else {
  result= classLoader.getResourceAsStream( name );
  if (result == null) {
  classLoader = this.getClass().getClassLoader();
  result= classLoader.getResourceAsStream( name );
  }
 }
This way the context class loader is used and if the resource is not
found, it falls back on the class' class loader.
This was my thought - but I was just trying to figure out what we'd break
if we did that...
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Geir Magnusson Jr                                  +1-203-665-6437
[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]