You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bi...@apache.org on 2002/08/19 05:28:41 UTC

cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes/sessions DummyCart.java

billbarker    2002/08/18 20:28:41

  Modified:    src/examples/WEB-INF/classes/sessions DummyCart.java
  Log:
  Make session value Serializable.
  
  With this, the session example makes a good test case for Context reloading.
  
  Revision  Changes    Path
  1.3       +2 -1      jakarta-tomcat/src/examples/WEB-INF/classes/sessions/DummyCart.java
  
  Index: DummyCart.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat/src/examples/WEB-INF/classes/sessions/DummyCart.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- DummyCart.java	8 Feb 2000 18:25:31 -0000	1.2
  +++ DummyCart.java	19 Aug 2002 03:28:41 -0000	1.3
  @@ -59,10 +59,11 @@
   package sessions;
   
   import javax.servlet.http.*;
  +import java.io.Serializable;
   import java.util.Vector;
   import java.util.Enumeration;
   
  -public class DummyCart {
  +public class DummyCart implements  Serializable{
       Vector v = new Vector();
       String submit = null;
       String item = null;
  
  
  

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Bill: It seems new Tomcat33 reloading has a ClassLoader problem

Posted by "Hugh J. L." <hu...@yahoo.com>.
Hi,

Thank you for your contribution to Tomcat and help on
me.

I wrote a simple class like below,

public class A implements java.io.Serializable {
    public void write() {
        System.out.println("can access" + this);
    }
}

and put the class file in WEB-INF/classes. Then I add
some lines into SessionExample.java.

Object o = session.getAttribute("test");
if (o == null) {
session.setAttribute("test", t);
            } else {
            	t =
(Hashtable)session.getAttribute("test");
            	((A)t.get("test")).write();
            }


--- Bill Barker <wb...@wilshire.com> wrote:
> This should be fixed now.  If you could test the
> latest nightly, it would be
> a big help.
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: It seems new Tomcat33 reloading has a ClassLoader problem

Posted by Bill Barker <wb...@wilshire.com>.
I can't reproduce this (ok, I'm lying, if you re-order "server.xml" enough,
you can do it :).  But I can't find a valid case where this occurs.

I've reversed the check between "Serialize", and "Copy" so that your
previous Hashtable example should now work.


----- Original Message -----
From: "Hugh J. L." <hu...@yahoo.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Sunday, August 25, 2002 7:02 PM
Subject: Re: It seems new Tomcat33 reloading has a ClassLoader problem


> When I was tracing into ObjectSerializer, I found that
> the class loader parameter it got was NOT the one
> passed to it in SimpleSessionStore. So the
> serialization was NOT done using our expected context
> class loader of the new context.
>
> Why? I can't explain this behavior...
>
> I simulated the serialization process in a servlet,
> which was loaded by the new context class loader as a
> matter of course, it worked well and the servlet could
> access the old object after serialization.
>
> Don't know if these clues are useful to you.
>
> Regards,
> Hugh
>
> --- Bill Barker <wb...@wilshire.com> wrote:
> > This is really going beyond Tomcat's ability to
> > detect.  Beans that want
> > this much control will need to be life-cycle aware
> > (e.g. implement
> > javax.servlet.http.HttpSessionBindingListener).
> > Alternatively, the Bean can
> > re-load the class when serialized.
> >
> > That having been said, I'm not really happy with the
> > life-cycle support on
> > the current patch.  It is currently too closely tied
> > to the
> > Intercepter/Facade split.  I may make it cleaner
> > later.
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: It seems new Tomcat33 reloading has a ClassLoader problem

Posted by "Hugh J. L." <hu...@yahoo.com>.
When I was tracing into ObjectSerializer, I found that
the class loader parameter it got was NOT the one
passed to it in SimpleSessionStore. So the
serialization was NOT done using our expected context
class loader of the new context.

Why? I can't explain this behavior...

I simulated the serialization process in a servlet,
which was loaded by the new context class loader as a
matter of course, it worked well and the servlet could
access the old object after serialization.

Don't know if these clues are useful to you.

Regards,
Hugh

--- Bill Barker <wb...@wilshire.com> wrote:
> This is really going beyond Tomcat's ability to
> detect.  Beans that want
> this much control will need to be life-cycle aware
> (e.g. implement
> javax.servlet.http.HttpSessionBindingListener). 
> Alternatively, the Bean can
> re-load the class when serialized.
> 
> That having been said, I'm not really happy with the
> life-cycle support on
> the current patch.  It is currently too closely tied
> to the
> Intercepter/Facade split.  I may make it cleaner
> later.
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: It seems new Tomcat33 reloading has a ClassLoader problem

Posted by Bill Barker <wb...@wilshire.com>.
This is really going beyond Tomcat's ability to detect.  Beans that want
this much control will need to be life-cycle aware (e.g. implement
javax.servlet.http.HttpSessionBindingListener).  Alternatively, the Bean can
re-load the class when serialized.

That having been said, I'm not really happy with the life-cycle support on
the current patch.  It is currently too closely tied to the
Intercepter/Facade split.  I may make it cleaner later.

----- Original Message -----
From: "Hugh J. L." <hu...@yahoo.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, August 22, 2002 10:42 PM
Subject: Bill: It seems new Tomcat33 reloading has a ClassLoader problem


> Hi,
>
> I wrote a simple class:
>
> public class A implements java.io.Serializable {
>     public void write() {
>         System.out.println("can access" + this);
>     }
> }
>
> and put the class file in WEB-INF/classes. Then I add
> some lines into SessionExample.java:
>
> Object o = session.getAttribute("test");
> if (o == null) {
>     session.setAttribute("test", new A());
> } else {
>     ((A)o).write();
> }
>
> After a context reloading, access to A object in old
> session caused ClassCastException at the line
> ((A)o)...
>
> Then, I tried another way to setAttribute:
>
> Object o = session.getAttribute("test");
> Hashtable t = null;
> if (o == null) {
>     t = new Hashtable();
>     t.put("test", new A());
>     session.setAttribute("test", t);
> } else {
>     t = (Hashtable)session.getAttribute("test");
>     ((A)t.get("test")).write();
> }
>
> It worked well after context reloading.
>
> Can you verify this problem?
>
> Thank you for your contribution to Tomcat and help on
> me.
>
> Regards,
> Hugh
>
> --- Bill Barker <wb...@wilshire.com> wrote:
> > This should be fixed now.  If you could test the
> > latest nightly, it would be
> > a big help.
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Sorry that the first email is imcomplete. Pls ingore it and read the second.

Posted by "Hugh J. L." <hu...@yahoo.com>.
 
 

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Bill: It seems new Tomcat33 reloading has a ClassLoader problem

Posted by "Hugh J. L." <hu...@yahoo.com>.
Hi,

I wrote a simple class:

public class A implements java.io.Serializable {
    public void write() {
        System.out.println("can access" + this);
    }
}

and put the class file in WEB-INF/classes. Then I add
some lines into SessionExample.java:

Object o = session.getAttribute("test");
if (o == null) {
    session.setAttribute("test", new A());
} else {
    ((A)o).write();
}

After a context reloading, access to A object in old
session caused ClassCastException at the line
((A)o)...

Then, I tried another way to setAttribute:

Object o = session.getAttribute("test");
Hashtable t = null;
if (o == null) {
    t = new Hashtable();
    t.put("test", new A());
    session.setAttribute("test", t);
} else {
    t = (Hashtable)session.getAttribute("test");
    ((A)t.get("test")).write();
}

It worked well after context reloading.

Can you verify this problem?

Thank you for your contribution to Tomcat and help on
me.

Regards,
Hugh

--- Bill Barker <wb...@wilshire.com> wrote:
> This should be fixed now.  If you could test the
> latest nightly, it would be
> a big help.
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Duplicate Contexts in reloading. Probably a sync bug in Tomcat 3.3.

Posted by Bill Barker <wb...@wilshire.com>.
This should be fixed now.  If you could test the latest nightly, it would be
a big help.

----- Original Message -----
From: "Hugh J. L." <hu...@yahoo.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, August 19, 2002 1:42 AM
Subject: Duplicate Contexts in reloading. Probably a sync bug in Tomcat 3.3.


> Hi,
>
> If two requests enter ReloadInterceptor.contextMap()
> simultaneously and both reload context, it causes
> duplicate context reloading.
>
> ---------- messages ----------
>
> 2002-08-19 16:15:16 - ContextManager: Removing context
> DEFAULT:/examples
>
> 2002-08-19 16:15:16 - ContextManager: Removing context
> DEFAULT:/examples
>
> 2002-08-19 16:15:16 - ContextManager: Adding context
> DEFAULT:/examples
>
> 2002-08-19 16:15:16 - ContextManager: Adding context
> DEFAULT:/examples
>
> ---------- messages ----------
>
> As a result, ContextManager.contextsV has duplicate
> Context object, while ContextManager.contexts doesn't
> have since it is Hashtable -- the first is replaced.
>
> I found this problem and then simulated it in JBuilder
> with its debugging functions.
>
> I think that it is not enough to sync DependManager
> only. It is necessary to sync some code in
> ReloadInterceptor.contextMap().
>
> So far don't know if this problem will cause further
> errors.
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Duplicate Contexts in reloading. Probably a sync bug in Tomcat 3.3.

Posted by "Hugh J. L." <hu...@yahoo.com>.
Hi,

If two requests enter ReloadInterceptor.contextMap()
simultaneously and both reload context, it causes
duplicate context reloading.

---------- messages ----------

2002-08-19 16:15:16 - ContextManager: Removing context
DEFAULT:/examples

2002-08-19 16:15:16 - ContextManager: Removing context
DEFAULT:/examples

2002-08-19 16:15:16 - ContextManager: Adding context
DEFAULT:/examples

2002-08-19 16:15:16 - ContextManager: Adding context
DEFAULT:/examples

---------- messages ----------

As a result, ContextManager.contextsV has duplicate
Context object, while ContextManager.contexts doesn't
have since it is Hashtable -- the first is replaced.

I found this problem and then simulated it in JBuilder
with its debugging functions.

I think that it is not enough to sync DependManager
only. It is necessary to sync some code in 
ReloadInterceptor.contextMap().

So far don't know if this problem will cause further
errors.

Thanks.


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>