tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <m...@phase.ws>
Subject RE: [SOLVED]RE: getResourceAsStream cached by Tomcat's Classloader?
Date Thu, 05 Jun 2003 19:47:44 GMT
I checked out tomcat from the HEAD and found the following information in
the WebAppClassloader:


I see now that the WebAppClassLoader does "intend" to have a cache for the
loaded Resources (some day).

---- code snip ----
WebappClassLoader - Line 1211
...
// (0) Check for a cached copy of this resource
stream = findLoadedResource(name);
...
---- code snip ----


It does this by examining the ResourcEntry(s) in the resourceEntries Hashmap
and checking binaryContent (null vs not null).

---- code snip ----
WebappClassLoader - Line 1898
...

/**
 * Finds the resource with the given name if it has previously been
 * loaded and cached by this class loader, and return an input stream
 * to the resource data.  If this resource has not been cached, return
 * <code>null</code>.
 *
 * @param name Name of the resource to return
 */
protected InputStream findLoadedResource(String name) {
  ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
    if (entry != null) {
      if (entry.binaryContent != null)
        return new ByteArrayInputStream(entry.binaryContent);
      }
    return (null);
  }
}

...

---- code snip ----

But, there is no caching going on when the resources are loaded. So, the
code is executing with no purpose? Matter of fact the code has //FIX ME
cache??? statements intermingled with the ClassLoader delegation.

---- code snip ----
WebappClassLoader - Line 1219
...
// (1) Delegate to parent if requested
if (delegate) {
    if (debug >= 3)
        log("  Delegating to parent classloader");
    ClassLoader loader = parent;
    if (loader == null)
        loader = system;
    stream = loader.getResourceAsStream(name);
    if (stream != null) {
        // FIXME - cache???
        if (debug >= 2)
            log("  --> Returning stream from parent");
        return (stream);
    }
}

// (2) Search local repositories
if (debug >= 3)
    log("  Searching local repositories");
URL url = findResource(name);
if (url != null) {
    // FIXME - cache???
    if (debug >= 2)
        log("  --> Returning stream from local");
    stream = findLoadedResource(name);
    try {
        if (hasExternalRepositories && (stream == null))
            stream = url.openStream();
    } catch (IOException e) {
        ; // Ignore
    }
    if (stream != null)
        return (stream);
}

// (3) Delegate to parent unconditionally
if (!delegate) {
    if (debug >= 3)
        log("  Delegating to parent classloader");
    ClassLoader loader = parent;
    if (loader == null)
        loader = system;
    stream = loader.getResourceAsStream(name);
    if (stream != null) {
        // FIXME - cache???
        if (debug >= 2)
            log("  --> Returning stream from parent");
        return (stream);
    }
}

// (4) Resource was not found
if (debug >= 2)
    log("  --> Resource not found, returning null");
return (null);
...
---- code snip ---

So there are three things that I can conclude as a result of seeing this
code.

1) My getResourceAsStream loading problems are NOT caused by Tomcat because
Tomcat is grabbing the resource fresh each time.
2) Resource caching still needs to be implemented in Tomcat
3) The caching check in Tomcat does not check resource Timestamps. So, even
if the cache was working it would not reload resources upon file changes.
(only binaryContent is being checked. eg null or not null).

Are my observations correct?

Brandon Goodin

-----Original Message-----
From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
Sent: Thursday, June 05, 2003 12:49 PM
To: Tomcat Users List
Subject: RE: [SOLVED]RE: getResourceAsStream cached by Tomcat's
Classloader?



Howdy,

>Dang it! I knew it was too good to be true. Well, it works just fine
for
>me.
>I do not deal with WARs. Anywyas, why would anyone want to run from a
>"packed" WAR anyways (instead of unpacked)? I'm not being sarcastic. I
am
>just trying to think of an instance where it makes sense.

Two cases come to mind:

- Running from a non filesystem-based server that can't unpack wars.
Oracle's servlet container was like this (at least used to be), as it
used the DB instead of the filesystem to serve resources.

- When you want to just have one file (the .war) for your app, and you
want to prohibit (for intellectual property legal protection etc.) users
from examining its contents.

Note that the servlet specification does not mandate filesystem support
for web applications.

That said, it's always a debate on whether WAR should be seen as a
packaging format only, to be unpacked on the server, or an equivalent to
an executable file on windows, which is one unit.

Yoav Shapira



This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message