Jonathan Halliday [
http://community.jboss.org/people/jhalliday] replied to the discussion
"beanifying the config"
To view the discussion, visit:
http://community.jboss.org/message/534922#534922
--------------------------------------------------------------
The problem of dynamically changing property values at point of use is actually orthogonal
to the one of holding the same property in multiple forms. Each is a synchronization
problem, but of different forms.
For any property, not just strings/classes, there is the question: when does a change to
the value in its canonical home (the EnvironmentBean) take effect in things that use that
property? The answer right now is: probably never. The value is read from the bean at
startup (or first use) and effectively cached at the point of use, usually in a static
variable. Therefore subsequent updates modify the bean but not the point of use and are
thus ineffective.
For properties that have dual representation e.g. String vs. Class, there is the question
of how/when updates to one of those representations affect the other. That's a much
more limited problem. Right now for example, putting a getName/getInstance pair on an
EnvironmentBean would just require figuring out the synchronization between them and
moving the classloading code from point of use to inside the bean. But it won't
address the problem that the point of use is calling either getName or getInstance once
only and not rechecking either for later updates.
Initially I'm just looking to reduce the duplication of classloading code and allow
for bean injection by putting Class getters/setters on the beans. After that I'll
worry about the dynamic change at point of use problem. The former has a generic solution
for all String/Class cases, whereas the latter will require individual examination of each
point of use. In many cases I think we can probably move from static variable to instance
variable and static initializer block to constructor for initializing it from the bean.
But it's related to lifetime and use of the object constructed.
For example, the useAlternativeOrdering applies in comparison of records, so changing that
will cause really screwy behaviour if it leads to comparing a set of records some of which
were created before and some after the change. In another case the port number for a
listener would require restarting that listener to take effect, which a) is not feasible
at present and b) would have consequence for any clients trying to connect if they
don't see the update at the same time. That's a distributed form of a problem that
also exists inside the same VM - how to coordinate updates where there is more than one
point of use for the same property and they need to be consistent. Should a component
restart be triggered from the bean, requiring the bean to have knowledge of its users, or
do we need an event registration mechanism so the listener can get a callback and restart
itself when the bean property is updated? As you an see there are some common themes, each
property's case is different and will need thinking about.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/534922#534922]
Start a new discussion in JBoss Transactions Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]