Re: [Springframework-developer] JavaBeans lifecycle considerations?

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

Juergen & Rob,

Thank you for your thoughtful replies. I will try to answer all
your questions hopefully not missing anything :)


> * Beans that want to can execute on their own thread
> 
> How is this supposed to work? The execution thread is  always
> determined by the caller of a bean's methods. In that respect,
> a bean can't execute "on its own thread", if I understand correctly.
> A bean can *create* its own threads though, either on initialization
> or on certain method calls. But in any case, the main method invocation
> will always execute in the caller's thread. Therefore I don't think that
> we need "own thread" support. Spring simply treats such thread starters
> as conventional beans, initializing them and making them available. It
> doesn't care if and when a bean starts and stops new threads - that's
> the bean's responsibility.

   There are two ways to do this. One is to call the onStart method
   on a separate thread and just let it run. When I was writing my email
   I was thinking about something like that but after reading your email
   I don't like that approach anymore. I agree that it should be a bean's
   responsibility to do whatever it needs to do, including starting its
   own thread of execution (and stopping it on onStop).


> * Bean pools (check-in, check-out)
> 
> As you've noted, Spring already supports the first two notions. Regarding
> bean pools, I'm not too convinced if they actually add value.
> In contrast to EJBs, beans are extremely lightweight, the on-demand
> creation overhead normally doesn't matter.

   I agree in general, but there are some cases when pooling is necessary.
   We all use it for database access. I need it for threads (can't think
   of anything else). Bean pools can be realised in a non-intrusive manner.
   For example, a bean pool can consist of a single interface provided
   facilities to create beans on-demand exist.


> Instance pooling would add a significant amount of overhead: There
> would indeed have to be an explicit checkout and check in, or a
> transparent checkout / check in on each method invocation, using an
> invocation proxy that delegates to the actual pooled instance. That
> may make sense for access to load-balanced remote services, but I

   I would go for the explicit check in/checkout. That is one more
   interface for a bean to support, but only if it wants to. I think
   this is consistent with Spring philosophy. And no changes to the
   rest of the framework would be required.


> * Load/unload beans
>  
> I guess you mean bean instances here, not bean classes

   Right, bean instances.


> and I assume load / unload means invoking initialize / dispose
> of predefined bean instances. I wonder what use cases you see for
> explicit beanFactory.load("myBeanName") and beanFactory.unload("myBeanName")
> calls. When would an application developer want to explicitly load
> and unload beans at runtime - maybe to make certain exported remote
> services available / unavailable?

   Exactly. For example:

   1. If there is a bean that performs certain services for other beans
      and it depends on some external resources. If those services
      become unavailable I need to manually replace the bean with something
      else. Or, I might need to load another bean pointing to a backup
      resource on the network (I might have restored the database from the
      dump, for example).

   2. My server consists from a series of plugins/services, and at any
      time I can load the ones I need. Sometimes I need something to
      happen at which time I can load the plugin. The plugin then registers
      a listener and starts to respond to application events (or it changes
      the application workflow somehow).

   3. It is needed for the bean pool :)


> * Persist bean configuration (not serialization, properties only)
>  
> Why would you want to persist a bean's property values - when would
> you want to load them again? Basically, the bean factory defines all
> property values, e.g. in a properties or XML file. Changing values at
> runtime should also occur via these files IMO, the modified file timestamp
> triggering a reconfiguration of the watching factory.

   You certainly don't want automatic reconfiguration as you won't
   be able to guarantee consistency. How would I be able to change the
   configuration programatically? Your approach would force me to understand
   how each factory stores configuration and I am not interested in that.

   I would like to be able to change a parameter and keep the parameter
   the next time application wakes up. This is probably a job for JMX
   (I'll mention it in my next email).

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