Servlet init(). & configuration changes.

Thread view:

Yogee - 18 Jun 2005 14:33 GMT

Hi,

I have a servlet that reads its configration from a xml file during
init().

A web based interface will be used to specify the configuration used by
the servlet. The interface will do a post on servlet and the servlet
will rewrite it's conf file.

My doubts:

what will happen to the ongoing post requests during which init will be
called in doPost(). Is it a good idea? Is it feasible?

what is the other way of telling a servlet about change in
configuration, without manual changes in the configuration.

Second question:
-------------------

There are other stand alone components which need to be notified of any
configuration changes. Is it a good idea to use telnet for this
components from the web interfaces to inform about changes in the
configuration.

All the components are bound to work in a LAN with all ports open
across each other.

Reply to this Message

John C. Bollinger - 18 Jun 2005 22:29 GMT

> I have a servlet that reads its configration from a xml file during
> init().
[quoted text clipped - 10 lines]
> what is the other way of telling a servlet about change in
> configuration, without manual changes in the configuration.

This general plan is a bit messy. In particular, you should understand
a few things about servlets (sorry if this is review for you):

1) A servlet instance is only initialized once, after which it may serve
many requests before being taken out of service.

2) The servlet container may take a particular servlet instance out of
service at almost any time, it its own sole discretion.

3) The servlet container may maintain a pool of instances for any
particular servlet.

4) A particular servlet instance may be called upon to handle multiple
concurrent requests, and therefore must be thread-safe.

Those characteristics have a lot of implications, but an important one
is that it is unwise for a servlet to have mutable instance variables,
for configuration or any other purpose. If you want online persistent
configuration then you should establish a shared configuration resource
outside the scope of the individual servlet instances, and you will need
to make sure that access to this resource is appropriately synchronized.
Servlets will need to obtain current configuration at every request.
One way to install such a resource into your web application is to use a
ServletContextListener.

> Second question:
> -------------------
[quoted text clipped - 6 lines]
> All the components are bound to work in a LAN with all ports open
> across each other.

The most appropriate mechanism for notifying other components surely
depends on the details of those components. Telnet from the web
interface doesn't sound particularly attractive, though. Better by far
would be for your central configuration resource to actively notify the
necessary components.

All in all, though, this sounds like a bit of a muddle.

Signature

John Bollinger
jobollin@indiana.edu

Reply to this Message

Yogee - 20 Jun 2005 07:12 GMT

> > I have a servlet that reads its configration from a xml file during
> > init().
[quoted text clipped - 25 lines]
> 4) A particular servlet instance may be called upon to handle multiple
> concurrent requests, and therefore must be thread-safe.

I m using the Java tech. for first time in my life. So, the review is
obvious. Thanx for enlightening me. Also where can I read internals of
servlets.

> Those characteristics have a lot of implications, but an important one
> is that it is unwise for a servlet to have mutable instance variables,
[quoted text clipped - 22 lines]
> would be for your central configuration resource to actively notify the
> necessary components.

All the configurations are stored in a database, when a person changes
the configuration, its the interface which knows about the changes
happening. So, I thought why not tell from there itself. I know its not
a GOOD thing.

Lets consider this:

Changes happened in database. Interface knows it, but cant tell?
Database can't tell anyone, unless someone do a select.

OR,

Other senario can be I run a provisioning server, central repsoitory
for configurations. It will keep all conf and everyone needs to have
permission from it to run the stuff. I can expose some applet on the
web that then talks to the PServer. It can be then used to do all sorts
of things.

OR,

SOAP. (Its last thing..)

> All in all, though, this sounds like a bit of a muddle.

Reply to this Message

John C. Bollinger - 22 Jun 2005 03:41 GMT

[...]

> I m using the Java tech. for first time in my life. So, the review is
> obvious. Thanx for enlightening me. Also where can I read internals of
> servlets.

You can download the servlet spec from Sun for free:
http://java.sun.com/products/servlet/download.html#specs

The latest version is 2.4, though there are still plenty of servlet
containers out there that implement only version 2.3 (e.g. Tomcat 4.x),
and some that are at earlier versions.

You may also want to look into JSP for the UI part; that spec is a
separate download, but it ties tightly into servlets.

>>> Second question:
>>> -------------------
[quoted text clipped - 22 lines]
> Changes happened in database. Interface knows it, but cant tell?
> Database can't tell anyone, unless someone do a select.

That's the least common denominator, to be sure.

> Other senario can be I run a provisioning server, central repsoitory
> for configurations. It will keep all conf and everyone needs to have
> permission from it to run the stuff. I can expose some applet on the
> web that then talks to the PServer. It can be then used to do all sorts
> of things.

Something along those lines is what I had in mind. An important aspect
to this, in response to your question about notification, is that your
provisioning server can have a mechanism to notify registered listeners
about configuration changes.

> OR,
>
> SOAP. (Its last thing..)

SOAP is a different kettle of fish. It could conceivably be the *means*
of notification, but it's just a protocol and cannot serve as the
*agent* of notification. In any case, if you already have standalone
applications that you want to notify then the details of those apps
determine the available means of notification. Unless they're already
tooled for it, SOAP probably isn't a particularly viable means.

Signature

John Bollinger
jobollin@indiana.edu

Reply to this Message

Servlet init(). & configuration changes.

Free Magazines