Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > how to get my servlet configuration before the servlet is initialised

Reply
Thread Tools

how to get my servlet configuration before the servlet is initialised

 
 
Andy Fish
Guest
Posts: n/a
 
      12-10-2003
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


 
Reply With Quote
 
 
 
 
Bob Rivers
Guest
Posts: n/a
 
      12-11-2003
"Andy Fish" <(E-Mail Removed)> wrote in message news:<D5GBb.1688$(E-Mail Removed)>...
> 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
 
Reply With Quote
 
 
 
 
John C. Bollinger
Guest
Posts: n/a
 
      12-11-2003
Bob Rivers wrote:

> "Andy Fish" <(E-Mail Removed)> wrote in message news:<D5GBb.1688$(E-Mail Removed)>...
>
>>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
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      12-11-2003
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
(E-Mail Removed)

 
Reply With Quote
 
Andy Fish
Guest
Posts: n/a
 
      12-17-2003
"John C. Bollinger" <(E-Mail Removed)> wrote in message news:<bral1a$lck$(E-Mail Removed)>...
> 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
> (E-Mail 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
static field initialised twice Thomas Hawtin Java 6 04-28-2006 06:05 PM
How to create an initialised object declared as a class member variable? CFF C++ 5 09-01-2004 08:24 PM
Test to see of a variable has been used/initialised Anon Java 39 05-02-2004 01:59 PM
Initialised class member objects claire.bell1 C++ 2 07-22-2003 05:56 AM
Includefiles with initialised variables? Joerg Toellner C++ 1 07-16-2003 10:18 AM



Advertisments