>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 reason I haven't responded is because I don't quite understand
the classloading system of Java, since I've just started
programming in Java recently.  So, I'm not exactly sure how the various
replies I've received apply to my situation.  They very well may,
but I don't quite get it.  Sorry.

My initial question was whether or not it is possible to control
the 'servlet life-cycle' under explicit program control, i.e., does
the servlet API provide a method to reload a servlet WHEN I SAY SO.
I believe the answer is no; it's handled by the servlet engine.

So, what I've ended up doing is moving the logic I want to be able
to update into a separate class, which I can then dispose of and
re-instantiate whenever I want to (by sending a certain request to
my control servlet).  I think this is what Steven Owens was suggesting
in his response.

Anyway, I believe my question was answered, and the problem solved.
Thanks.

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

Reply via email to