aspose file tools*
The moose likes Servlets and the fly likes Error dissapears after re-starting TOM CAT.. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Error dissapears after re-starting TOM CAT.." Watch "Error dissapears after re-starting TOM CAT.." New topic
Author

Error dissapears after re-starting TOM CAT..

Gabriel Fox
Ranch Hand

Joined: Oct 17, 2001
Posts: 170
Hi guys, i just want to make myself clearer
with this post.What causes these errors when a form is submitted to a controller servlet
a. SessionSerializer:java.io.NotSerializableException:
b.java.lang.ClassCastException:
c.Internal Servlet Error:
After re-starting Tomcat and submitted same pages a number of time this error DID NOT show up again.
What is the problem.
The line no specified in the error message has correct casting.Besides, i have not touched the controller servlet for ages.
All ideas are welcomed.Cheers.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

I have not looked into the source code for Tomcat (or your code), so I am only speculating!

Sometimes a servlet container may choose to serialize some of it's objects to conserve memory. Other containers provide 'fail-safe' distributed services by doing the same thing.. serializing the objects and sending them to the next JVM in the cluster.

Perhaps you've "gotten away with it" up to now, but a number of events might have combined to make Tomcat serialize something 'for the first time', and you see it as a strange and non-reproducible error, months after you think it's working. I love it when that happens.

If you mostly use the API provided objects (Vectors, HashMap, etc) then you are pretty much guaranteed that your objects will be serializable. But if you make your own (like 'Customer' or 'Order'), then perhaps these are not serializable.

As for your ClassCastException, I'd have to see code before getting into that one.

And for the third: 'Servlet Error' is the generic explanation displayed on the page, whenever either of the first two occur.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

Most of the time I see a ClassCast in Tomcat (and Weblogic, possibly other servers) is due to the way it handles ClassLoaders.
Without going into the details, Servlets and JSPs have separate ClassLoaders, so if your usual flow is:
  • submit a query to a Servlet,
  • place a custom object on the request (eg Customer or User)
  • redirect to the JSP for display

  • If you alter the JSP (and it gets compiled and reloaded by Tomcat) and then reload the page, it ends up loading the Class twice and trying to treat the two versions the same but cannot decide if they are the same Class or not. Hence the ClassCastException when you try to get it back from the request object.
    The infuriating bit is that if you have code like this:
    Then try to work out what is coming back:

    it returns "MyObject"
    I haven't tested it, but you might be able to detect the problem using something like this:

    You might be able to see that the ClassLoaders are different.
    Dave
    Gabriel Fox
    Ranch Hand

    Joined: Oct 17, 2001
    Posts: 170
    Cheers guys U ideas are appreciated.
    1.But,Dave i find it difficult to include the logic checking the classloader,because the error happens whenever it wishes.
    Below is the first 2 lines of my controller servlet doPost().The line no specified on the Tomcat Console is line 2 of my doPost().
    I have checked all instance variables in my SchemeBean and found out that some of the classes DO NOT implement java.io.Serializable. But , is this a problem .The javabean class (SchemeBean) defined implements java.io.Serializable.
    class ControllerServlet extends HttpServlet
    {
    x.y.g.k.PackA.PackB.SchemeBean beanRef=null;
    HttpSession session ;
    public void doPost(HttpServletRequest request,HttpServletResponse response) throws IOException,ServletException
    {
    session = request.getSession(true);
    beanRef=(x.y.g.k.PackA.PackB.SchemeBean)session.getAttribute("beanName"); // Error Line
    -----------
    -----------
    }
    }
    2.How can i know more about issues evolving due to ClassLoaders in Web applications.
    3. Lastly, how do i write a powerful error page (JSP)which captures NOT just exceptions , but all kinds of errors.
    All ideas and references will be appreciated .
    [ May 13, 2002: Message edited by: Gabriel Fox ]
    David O'Meara
    Rancher

    Joined: Mar 06, 2001
    Posts: 13459

    If you modify the line

    to be

    It will still throw the ClassCastException, but you will see that the class is the type you wanted it to be, it is unable to cast it into the class that it actually is supposed to be: because it no longer recognises the class.
    There is documentation on the multiple Tomcat ClassLoaders here.
    An important note is that you should only have these problems during development and never in production, since you won't be fircing JSPs to recompile on the live site. Therefore you shouldn't worry about it too much.
    If you do need an absolute fix, there is an evil solution. You can pass an instance of your Class and get it to forget the previous ClassLoader, but at a cost. If you make the Class Serializable, you can use Piped ObjectStreams to disconnect the 'illegal' version of your instance, and get it to create a 'legal' instance - at a cost.
    Please (please) note I'm not recommending this, it isn't really required and restarting Tomcat isn't that hard.
    This is untested, but something like this:

    ...or something like that.
    Dave
    Gabriel Fox
    Ranch Hand

    Joined: Oct 17, 2001
    Posts: 170
    Cheers Dave, your logic , reference and time is well appreciated.It comes with experience.
    David O'Meara
    Rancher

    Joined: Mar 06, 2001
    Posts: 13459

    Theres nothing like tracking down a problem like that on your own though
    I meant to have a say on your 'single mega-error page' question.
    Others will probably have another say, but I always try to have all processing in a Servlet, and do as little in a JSP as possible.
    (IMHO etc) The biggest weakness in automatic error pages is when you have a complicated JSP or series of JSPs and you can't tell if the response is commited or not. If the JSP is small and simple, there is less danger of the response being commited before the exception is thrown so you'll always get to the erro page.
    Its also trivial to extend an error page so that it can manage Exceptions trapped in Servlets so they can throw to it too.
    Dave
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Error dissapears after re-starting TOM CAT..
     
    Similar Threads
    Passing object from Servlet to JSP throws Exception
    when is the destroy method called?
    refresh resubmits form
    Number calculations
    value from servlet to dropdown in jsp