Brian Stansberry [
http://community.jboss.org/people/bstansberry%40jboss.com] replied to
the discussion
"model updates and references"
To view the discussion, visit:
http://community.jboss.org/message/559569#559569
--------------------------------------------------------------
I see us having a separate layer, not doing modifications directly on the core model. But
we need to start actually fleshing this out to see how it works. I want to start with
deployments; perhaps you can identify one or two more types of modifications that are
fairly representative of different types of problems we need to handle?
David might want to comment further, but I think we should look at the
AbstractModelElement.appendDifferences() method as an initial idea on how to deal with
updates, something we can supplement or even move away from completely. It's based on
the idea that we have another instance of the model and we then calculate differences and
based on those create update actions. It's not clear where that other instance of the
model comes from. One of the nice aspects of the appendDifferences idea is only update
classes have access to the package-protected modifier methods on the model objects. But
then how is the other instance of the model created?
Re: validation -- forgive me for a bit of a tangent: even with the more limited task
we've done up to now of creating model objects by parsing, I think we're missing
an explicit validation phase. For one thing, it's needed to give model elements a
chance to resolve any references to other model elements. I've done a bit of that with
RefResolver being passed into model element constructors, but there are cases where
it's not valid to try and resolve the reference in the constructor (since the referent
may not have been parsed yet). Now we're not resolving until the element is activated,
which is too late.
When we talked a week or so ago about a proper reference notion, I was thinking mostly in
terms of the rename use case. So if socket-binding "foo" gets renamed
"bar", any referring elements are aware of that and change their config to read
"bar". But I think a richer reference notion can apply to other problems as
well. For example, ServerGroupElement has a fully fleshed out "reference object"
linking it to a ProfileElement. So if the ProfileElement is changed (either directly or
via a change to a child subsystem) the ServerGroupElement is aware of that. We then use
that information to figure out what to push out to the ServerManagers (and on to the
Servers).
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/559569#559569]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]