Cezar--

Sun's ClassLoading system is by far one of Java's greatest strengths; what's
more, it's happening, whether you want it to or not, under the hood, and
having a good understanding of the ClassLoading system is critical to
sophisticated Java development, IMHO. What's worse, Java 2 changed some of
the rules regarding ClassLoaders (introducing the new "delegation" concept
to the mix), so what you may have known from JDK 1.1 suddenly doesn't
*quite* hold with 1.2. Frustrating, to say the least, especially when
working with ClassLoaders that don't play by the same rules.

The ClassLoader defines the namespace for a Class. That is, a given loaded
class is known by its name-ClassLoader combination. Static instances are
global across all instances of that Class WITHIN THAT CLASSLOADER; that's a
key key key thing. If I do this:

import com.javageeks.classloader.FileSystemClassLoader;

public class StaticCounter
{
    public static int count = 0;
    public StaticCounter() { count++; }
}

public class StaticCounterMain
{
    public static void main(String[] args)
        throws Exception
    {
        for (int i=0; i<20; i++)
        {
            ClassLoader cl = new
FileSystemClassLoader("/usr/local/classes");
            Class c = cl.loadClass("StaticCounter");
            Object o = c.newInstance();

            // Use Reflection to find the "count" member
            int o_count = <StaticCounter.count from Reflection>;
            System.out.println("o_count = " + o_count);
        }
    }
}

Every single time, StaticCounter.count will be reported as 0; because it's
loaded into a new ClassLoader each time, it gets fresh copies of all its
statics.

To answer your concerns,

>- Cant figure if servlet engine checks newer versions only for servlet
>  classes (insufficient) or for any class  used within my app.
> (that's expensive!) ?
>
Servlet engine has nothing to do with it; it's all ClassLoaders. You can
accomplish the same thing outside of the servlet engine completely. As a
matter of fact, just about every EJB server has to do this on each EJB's
activation (as I understand it).

>- When does it checks? When I create a new instance or when I use it?
>  Or when I access static methods or variables?
>
At time of ClassLoading. That is, when you call loadClass() on the
ClassLoader (which in turn is called by Class.forName(), for example), the
ClassLoader will retrieve the code from wherever its supposed to do so;
URLClassLoader, for example, retrieves it from an array of URLs (which
includes the CLASSPATH entries). Other ClassLoaders can pull it from other
places, like a Socket, the local disk, or even manufacture the code on the
fly, if they want.

>- What happens with existing living instances of old classes
>  refferenced within sessions, static vars or contexts ?
>
When a new ClassLoader is opened, existing ClassLoaders are left alone. Each
ClassLoader is its own, independent Class namespace, and retains its own
copy of the code. This means that if you load class "Foo" into ClassLoader
A, modify the Foo.class file on disk, then create ClassLoader B and call its
loadClass("Foo"), you'll get the modified Foo, but the first one remains
identical.

If you don't believe me, I've got a sample I can send to you to prove it. :)

Ted Neward
Patterns/C++/Java/CORBA/EJB/COM-DCOM spoken here
http://www.javageeks.com/~tneward
 "I don't even speak for myself; my wife won't let me." --Me

-----Original Message-----
From: Cezar Totth <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, June 29, 1999 1:58 AM
Subject: Re: Can one servlet unload another?


>Hi,
>
>Actually I don't trust at all this reloading of new (changed) classes
>within servlet engine's class loader, being servlets or not, for several
>reasons:
>
>So I choose, at least for developing, a small servlet engine that
>doesnt take long to restart - the JSDK's is most convenient for me.
>
>Bye,
>
>Cezar.
>
>On Mon, 28 Jun 1999, Bill O'Keefe wrote:
>
>> >I think te original poster wants to load on demand a new version of the
>> >servlet's class - a method like:
>> >
>> > ServletContext.markObsolete(Servlet myservlet);
>> >
>> >in order to inform the context to reload (through class loader)
>> >when a new request comes.
>> >This  opposed with expensive dynamic reloading provided by some web
servers .
>> >
>> >There is no such method in JSDK.
>>
>> Yes, this is basically what I wanted to do.  Since there doesn't
>> appear to be such a method, do you have any idea how this could
>> be implemented?  Or, it this basically something that would have
>> to be added to each servlet engine?  Thanks,
>>
>> >
>> >Cezar.
>> >On Thu, 24 Jun 1999, James Duncan Davidson wrote:
>> >
>> >> > I looked through the servlet spec, and didn't see any
>> >> > way to do this, but I just want to know for sure.
>> >> > Bascially, I'm looking for a way to reload a servlet
>> >> > without shutting down the web server.  I don't want to
>> >> > use the dynamic reloading facility, since I don't
>> >> > want the server to check the timestamp on my servlet
>> >> > on every request (I like that feature during development,
>> >> > but not in a production site.)  So, I want a way to
>> >> > reload a servlet under program control (i.e., what
>> >> > the Admin server does when you set Loaded Now? to no).
>> >>
>> >> Servlet loading is under the control of the container that the
servlets
>> >> are part of. Why do you need to reload a servlet during runtime if you
>> >> aren't trying to reload? Can't you call some sort of synchronized
clear
>> >> method (that you implement) that will reset your servlet?
>> >
>> >I understood he wants to load a new version of the servlet, not just to
>> >clear it.
>>
>> That is correct.
>>
>>
>>     -- Bill
>>
>> --
>> Bill O'Keefe                                     [EMAIL PROTECTED]
>> Open Market, Inc.                            http://www.openmarket.com/
>> One Wayside Road                                 TEL: 781.359.7296
>> Burlington, MA 01803                             FAX: 781.359.8200
>>
>>
___________________________________________________________________________
>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>> of the message "signoff SERVLET-INTEREST".
>>
>> Archives: http://archives.java.sun.com/archives/servlet-interest.html
>> Resources: http://java.sun.com/products/servlet/external-resources.html
>> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>>
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to