Bernhard Huemer schrieb:
> If you compile and refresh asynchronously without having old states
> of the objects not only the classes you basically exchange classes
> and objects in the middle of a request. Ok granted this does not
> happen to often but it can happen!
> So what happens, is that a) the user has to wait in the middle of
> request processing that the atomic compile and refresh is done (or
> not depending what you want to lock there) and then to the worse
> you suddenly in the middle of the request you have the beans and
> classes exchanged.
> Ok this is not too different to what happens if you refresh in
> request level if you dont streamline the requests during the
> compile and refresh cycle.
> So pretty much you end up with one request in an inconsistent
> state and probably errors.
Yes, both beans and classes will be refreshed at any time during the
request, but unfortunately I can't see how that - and please correct me
if I'm wrong as I think you haven't really explained that either -
introduces inconsistency. It's basically just a clone using a different
class, in fact (if it wouldn't raise a ClassCastException) you could
even call something like oldBean.equals(newBean) and it would return
true. Apart from the fact that the new bean is an instance of a
different class, those two versions don't differ at all. Well, the fact
that they're using two different classes might seem like big deal at
first, I mean, if that's not a huge difference, what else is?
Ok again sleeping over it a while, in most cases it works
but there is definitely a corner case where beans get replaced and run
into a classcast exception. I know this is nitpicky but
lets start this again because I want to discuss that further!
There is a corner case where the beans will be replaced on the fly
and yet still you run into classcast exceptions if you dont do
the replacement during request start!
(It comes down to it because you can double buffer the compile so that
every request has a consistent state)
Lets have the look at the example again
A and B b is loaded in the code from A dynamically by
applicationContext.getBean("B")
A is altered and B
A does some long running processing
both beans get exchanged on the fly,
however the old A has not finished its processing
and in the middle of it it does applicationContext.getBean("B")
while A definitely will be replaced
this will cause a classcast exception because the processing is not done.
This is a classical reporting situation where you have something long
running which references other beans and it works asynchronously!
So it comes down to either force the user to use managed properties for
this or live with an occasional hickup like that.
Dont get me wrong, A and B are exchanged both, and after the long
running request is finished things work again, so only one request is
lost. But this corner case definitely is one which is bound to fail
if you dont have a consistent class state between the beginning and end
of processing.
If you alter just B and keep A as it is then you are bound to fail
anyway because the system for now cannot detect any dependency between
those two (a class dependency scan would be needed which scans the
imports) to resolve that.
Anyway I can live with any state regarding the reloading for 1.0 because
we talk about needle in a haystack situations here which are absolute
corner cases! In the end to resolve everything cleanly you probably have
to do parsing on classlevel to find the dependencies out properly.
So lets close this discussion, because after sleeping over it for a few
days for now any solution regarding the state is viable for 1.0 we talk
about a scripting extension here, and scripting languages are way
dirtier regarding those issues than we are.
