how to get my servlet configuration before the servlet is initialised

[Andy Fish]

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

 

[Bob Rivers]

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

 

[John C. Bollinger]

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
(e-mail address removed)

 

[John C. Bollinger]

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
(e-mail address removed)

 

[Andy Fish]

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
(e-mail address removed)

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.