how to get my servlet configuration before the servlet is initialised

Discussion in 'Java' started by Andy Fish, Dec 10, 2003.

  1. Andy Fish

    Andy Fish Guest

    Hi,

    I have recently had a problem with servlet initialisation and I figured out
    that on startup, tomcat was deserialising instances of my classes that were
    held in session variables when it was shut down the previous time.

    Tomcat does this before initialising the servlet. Unfortunately the class in
    question cannot sensibly be initialised without knowing the servlet
    configuration parameters, and I can't get hold of them until the servlet is
    initialised.

    I seem to be in a catch 22 here. I don't want to hard code knowledge in my
    class about where the servlet configuration will be, but I can't initialise
    the class without it, and I can't stop tomcat deserializing the objects.

    any clues anyone?

    Andy
     
    Andy Fish, Dec 10, 2003
    #1
    1. Advertising

  2. Andy Fish

    Bob Rivers Guest

    "Andy Fish" <> wrote in message news:<D5GBb.1688$>...
    > Hi,
    >
    > I have recently had a problem with servlet initialisation and I figured out
    > that on startup, tomcat was deserialising instances of my classes that were
    > held in session variables when it was shut down the previous time.
    >
    > Tomcat does this before initialising the servlet. Unfortunately the class in
    > question cannot sensibly be initialised without knowing the servlet
    > configuration parameters, and I can't get hold of them until the servlet is
    > initialised.
    >
    > I seem to be in a catch 22 here. I don't want to hard code knowledge in my
    > class about where the servlet configuration will be, but I can't initialise
    > the class without it, and I can't stop tomcat deserializing the objects.
    >
    > any clues anyone?
    >
    > Andy


    I don't know if I understood your question (english isn't my natural
    language) but I will try to describe what I do.

    Basically I have one servlet, called ServletInit, that I use to parse
    a config file, then I store the parsed information into a session.

    The trick is to configure your web.xml in order to show to tomcat that
    he must load this servlet before the other ones (so the other ones can
    read the session attributes in order to run properlly). The line who
    take care of this task is <load-on-startup>1</load-on-startup>:

    <servlet>
    <servlet-name>init</servlet-name>
    <servlet-class>com.mycompany.core.servlets.ServletInit</servlet-class>
    <load-on-startup>1</load-on-startup>
    </servlet>

    The ServletInit must have a method called init. This method does the
    parse thing that I said.

    Bob
     
    Bob Rivers, Dec 11, 2003
    #2
    1. Advertising

  3. Bob Rivers wrote:

    > "Andy Fish" <> wrote in message news:<D5GBb.1688$>...
    >
    >>Hi,
    >>
    >>I have recently had a problem with servlet initialisation and I figured out
    >>that on startup, tomcat was deserialising instances of my classes that were
    >>held in session variables when it was shut down the previous time.
    >>
    >>Tomcat does this before initialising the servlet. Unfortunately the class in
    >>question cannot sensibly be initialised without knowing the servlet
    >>configuration parameters, and I can't get hold of them until the servlet is
    >>initialised.
    >>
    >>I seem to be in a catch 22 here. I don't want to hard code knowledge in my
    >>class about where the servlet configuration will be, but I can't initialise
    >>the class without it, and I can't stop tomcat deserializing the objects.
    >>
    >>any clues anyone?
    >>
    >>Andy

    >
    >
    > I don't know if I understood your question (english isn't my natural
    > language) but I will try to describe what I do.
    >
    > Basically I have one servlet, called ServletInit, that I use to parse
    > a config file, then I store the parsed information into a session.
    >
    > The trick is to configure your web.xml in order to show to tomcat that
    > he must load this servlet before the other ones (so the other ones can
    > read the session attributes in order to run properlly). The line who
    > take care of this task is <load-on-startup>1</load-on-startup>:
    >
    > <servlet>
    > <servlet-name>init</servlet-name>
    > <servlet-class>com.mycompany.core.servlets.ServletInit</servlet-class>
    > <load-on-startup>1</load-on-startup>
    > </servlet>
    >
    > The ServletInit must have a method called init. This method does the
    > parse thing that I said.


    If you want to accomplish webapp initialization then doing it via a
    load-on-startup servlet is a hack that may come back to bite you later.
    (Or may never do, but why risk it?) The servlet API has a way of
    expressing this sort of thing more naturally: a ServletContextListener
    implementation configured in the webapp's deployment descriptor. Not
    only is that better suited to the task, but it also avoids having a
    servlet that isn't really a servlet.

    Moreover, if the OP's problem is that his sessions are being
    deserialized before his servlets are suitably initialized then a
    load-on-startup servlet very well might not load soon enough to solve
    the problem anyway.


    John Bollinger
     
    John C. Bollinger, Dec 11, 2003
    #3
  4. Andy Fish wrote:

    > I have recently had a problem with servlet initialisation and I figured out
    > that on startup, tomcat was deserialising instances of my classes that were
    > held in session variables when it was shut down the previous time.
    >
    > Tomcat does this before initialising the servlet. Unfortunately the class in
    > question cannot sensibly be initialised without knowing the servlet
    > configuration parameters, and I can't get hold of them until the servlet is
    > initialised.
    >
    > I seem to be in a catch 22 here. I don't want to hard code knowledge in my
    > class about where the servlet configuration will be, but I can't initialise
    > the class without it, and I can't stop tomcat deserializing the objects.
    >
    > any clues anyone?


    It sounds like you need a bit of a redesign. Servlet state that will
    not vary from instance to instance should be moved to the application
    context and initialized either via context parameters or a
    ServletContextListener (see my other response) or both. You should not
    store anything in a session (or in the application context) that depends
    on the unique state of a _particular_ servlet instance, because you
    cannot rely on ever seeing that instance again. The container is
    permitted to release it at will and create a new one later when needed.

    A possible intermediate hack is to mark the problematic fields
    "transient" so that they will not be serialized. You do then still have
    to worry about reinitializing them some time after deserialization.
    This is not a true solution, just a workaround in case it would be too
    big a job to do the Right Thing.

    If you can describe what you are trying to do in more detail then
    perhaps you will get some suggestions of higher specificity.


    John Bollinger
     
    John C. Bollinger, Dec 11, 2003
    #4
  5. Andy Fish

    Andy Fish Guest

    "John C. Bollinger" <> wrote in message news:<bral1a$lck$>...
    > Andy Fish wrote:
    >
    > > I have recently had a problem with servlet initialisation and I figured out
    > > that on startup, tomcat was deserialising instances of my classes that were
    > > held in session variables when it was shut down the previous time.
    > >
    > > Tomcat does this before initialising the servlet. Unfortunately the class in
    > > question cannot sensibly be initialised without knowing the servlet
    > > configuration parameters, and I can't get hold of them until the servlet is
    > > initialised.
    > >
    > > I seem to be in a catch 22 here. I don't want to hard code knowledge in my
    > > class about where the servlet configuration will be, but I can't initialise
    > > the class without it, and I can't stop tomcat deserializing the objects.
    > >
    > > any clues anyone?

    >
    > It sounds like you need a bit of a redesign. Servlet state that will
    > not vary from instance to instance should be moved to the application
    > context and initialized either via context parameters or a
    > ServletContextListener (see my other response) or both. You should not
    > store anything in a session (or in the application context) that depends
    > on the unique state of a _particular_ servlet instance, because you
    > cannot rely on ever seeing that instance again. The container is
    > permitted to release it at will and create a new one later when needed.
    >
    > A possible intermediate hack is to mark the problematic fields
    > "transient" so that they will not be serialized. You do then still have
    > to worry about reinitializing them some time after deserialization.
    > This is not a true solution, just a workaround in case it would be too
    > big a job to do the Right Thing.
    >
    > If you can describe what you are trying to do in more detail then
    > perhaps you will get some suggestions of higher specificity.
    >
    >
    > John Bollinger
    >


    Unfortunately it wasn't me who wrote the code. looking at it now, I
    see that the class in question implements Serializable (when it
    patently shouldn't) and I guess that's the actual cause of the
    problem. Unfortunately I have a feeling that if I remove "implements
    Serializable" something else might break.

    the object in question is not really a lightweight serializable
    'value' - it's part of the application with many links to other
    objects etc. I'm pretty sure it was never intended to be serialized as
    part of a session and I was blaming tomcat for doing it when really it
    was the programmers fault for having it implement serializable

    as you said, a redesign is probably in order.
     
    Andy Fish, Dec 17, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anon
    Replies:
    39
    Views:
    2,120
    Joona I Palaste
    May 2, 2004
  2. Thomas Hawtin

    static field initialised twice

    Thomas Hawtin, Apr 27, 2006, in forum: Java
    Replies:
    6
    Views:
    630
    Chris Smith
    Apr 28, 2006
  3. Joerg Toellner
    Replies:
    1
    Views:
    322
    Jakob Bieling
    Jul 16, 2003
  4. claire.bell1

    Initialised class member objects

    claire.bell1, Jul 21, 2003, in forum: C++
    Replies:
    2
    Views:
    430
    John Harrison
    Jul 22, 2003
  5. CFF
    Replies:
    5
    Views:
    586
    Michael Chisholm
    Sep 1, 2004
Loading...

Share This Page