Re: [Springframework-developer] JavaBeans lifecycle considerations?

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

> You mean a bean that kicks off an asynchronous process somehow? But what
> would it return to the caller? We probably do need more sophisticated thread
> models for app context event listeners. At present the multicast event
> listener uses the same thread as the call that created the event, allowing a
> rogue listener to lock the app. It would be easy to support several options,
> with this the default, as it's low overhead if people implement their
> listeners properly. (Ie a listener kicks off a background thread if it needs
> to).

   It sounds like something the framework needs, although I did not have a
   need for such functionality in my projects.


> This is a very interesting area. Semi-coherent braindump follows.
> 
> Do we want to call additional setters on a running bean? e.g.
> setRetryCount(n) to a new value? This might be appropriate in some cases,
> especially for simpler things. Yet it would place constraints on beans,
> implying that some metadata might be required to indicate which fields were
> refreshable.

   Metadata sounds too complex. I would go for a black&white approach.
   Either a bean is reconfigurable or not. Reconfiguration makes sense the
   most with service beans and I guess that those would be the ones that would
   expose themselves as reconfigurable.

   I have a fear that we can build this but that it would become too
   complex. The only simple solutions is the one when you explicitly
   check beans in and out, and there you can treat one cycle as a
   transaction. Idle beans are obviously safe to reconfigure.

   Or can we confine ourselves to only reconfigure service beans. For
   example: call stop, reconfigure, call start (or do it transparently,
   which is probably easier).


>>* Reload bean class (in combination with bean pools this probably means
> 
> that multiple bean versions will run in parallel at times)
> 
>>We would need own classloader hierarchies for such stuff. Basically, every
> 
> bean instance would have to be loaded in its own classloader to achieve
> this. I rather consider classloader handling an issue for J2EE containers,
> not for application frameworks, due to all the nasty hassles that are
> involved. And as I've outlined above, this is really hard if not impossible
> to handle properly in a concurrent environment, as any bean can have
> dependencies on any other. How to guarantee consistency within the whole
> system here?
> 
> I don't want to get into class loading, if we can possibly help it.

   OK, let's forget about that for the moment. I am not too keen either.



>>* Persist bean configuration (not serialization, properties only)
> 
> Isn't the XML doing this?

   What do you mean?


>>* 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.
> 
>>Basically, a Spring BeanFactory resp. ApplicationContext matches that
> 
> role, although these interfaces represent a bean user API, avoiding bean
> definition details. Implementation classes like AbstractBeanFactory,
> ListableBeanFactoryImpl, and AbstractApplicationContext offer access to such
> SPI details too. With some added methods e.g. for loading/unloading,
> sufficient control and inspection capabilities should be available.
> 
> What about JMX? So long as it could be done without forcing JMX complexity
> on user code.

   Now, JMX is a very interested technology. I did not want to mention
   it before to avoid getting lost in discussion and because I am still
   investingating it.

   From what I've seen so far it should be possible to add a JMX layer
   to Spring and transparently expose JavaBeans that form the application.
   Not all beans should be exposed, we could mark the ones we want in
   the configuration somehow.

   Most of the features I have mentioned here have their place in JMX
   and some of them would be required in order to fully support it. But
   I am still playing with the spec. and the reference implementation,
   and I haven't formed my final opinion about it.

   But even know it is obvious that JMX fits naturally to the existing
   Spring functionality.

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