Servlet init(). & configuration changes.

[Yogee]

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.

 

[John C. Bollinger]

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.

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:
-------------------

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.

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.

 

[Yogee]

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.

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,
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.


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 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..)

 

[John C. Bollinger]

John C. Bollinger wrote:
[...]

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.

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.

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.