Re: [Springframework-developer] JavaBeans lifecycle considerations?

[Ivan R. <iv...@we...>]

> You are very welcome to join us and work on this! Rod and
 > me will be happy to provide you with details on the current
> bean factory and application context concepts :-)

   That is great to hear. I've spent some time today playing
   with the framework to get a feel of what's possible. Here
   are my notes.

   There are many ideas/features mentioned here but not all
   are equally important. Personally I would start simply
   but adding the equivalent to start/stop/dispose methods
   as they will benefit the majority of those building standalone
   applications. Other features are nice, but not
   essential.

   ...


Some background
---------------

I've spent the last year or so dealing with a Java daemon
application (a RADIUS server). As part of that project I've
built a framework similar to what I describe below, but not as
fancy. Well, I couldn't really call that a framework since
there wasn't much time to design it upfront, but it works
and it works well. This server consists of many components
that are configured and wired at runtime from an XML-based
configuration, just like the Spring framework.

That was for work. After completing the project I decided to
rebuild the framework from scratch for fun, so here I am.


Requirements
------------

* Complete bean life cycle: parameters, initialisation,
   start, stop, suspend, resume, reconfigure, dispose/destroy.

* Beans that want to can execute on their own thread

* Singleton/shared and not-shared beans

* Ability to safely reconfigure a bean that is referenced
   by other beans

* Load/unload beans

* Bean pools (check-in, check-out)

* Reload bean class (in combination with bean pools this
   probably means that multiple bean versions will run
   in parallel at times)

* Persist bean configuration (not serialization,
   properties only).


Notes
-----

At the moment Spring supports parameterization and initialization
(with the InitializingBean interface). It would be simple
to add one or more interfaces to support methods such
as: start, stop, dispose/destroy (other names can be chosen
to avoid clash with the Thread class).

As an idea, beans implementing the Runnable interface could
be launched as daemon threads. I am more against than for
this idea (but you may think otherwise).

I have also considered detecting a "main" method on an object
and invoking it, simulating a command line. I am more against
than for this idea (but you may think otherwise).

We could have suspend/resume, or we can simply use start/stop
for that purpose. I am not really sure. I lean toward using
a single pair of methods, start and stop.

Reconfiguring a bean is a bit more complicated. I was
thinking about using proxies to intercept method invocations,
wait until all method executions are completed, reconfigure
the bean, and then resume. We would probably need to call
stop/suspend before and start/resume after. The process
with loading/unloading would be similar.

Spring also supports singleton and not-shared beans at the
moment. There is a space in between to support bean pools.
I don't think that this can be supported transparently, there
would have to exist a check in/checkout process. For example,
a client bean would receive a reference to a bean pool
and ask it for bean instances when required.

When reconfiguring bean pools, there could be an option whether
to only create new beans with new configuration (possibly removing
all idle beans immediately) and let busy beans finish with their
work, or reconfigure all bean instances.

Finally, a container needs to be written which would allow
access to all beans and their configuration from the outside,
plus options to load/unload beans, reconfigure them, inspect
them and so on. On a related note, I have also started work on
a utility scripts that would allow tight integration of Java
daemons with UNIX and Windows operating systems.

Links
-----

Some links to similar projects. I would say that they
are all far more complicated than I would want.

http://avalon.apache.org/framework/
http://www.picocontainer.org/
http://jakarta.apache.org/commons/sandbox/hivemind/

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]