1:09 p.m.
Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the
discussion
"model updates and references"
To view the discussion, visit: http://community.jboss.org/message/559596#559596
--------------------------------------------------------------
Brian Stansberry wrote:
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?
Yeah, i do think that a separate layer would be more interesting. At least changes should
be decoupled from the core model - what i mean is that if you have someone editing the
domain configuration, we should do a diff based on the edited "version" and then
only apply the changes to the core domain model.
Hmm some modifications i have in mind are:
-) subsystem updates - since they are part of extensions
-) creating new subsystems - since they might require an <extension /> module
-) a domain deployment used by 2 server-groups... where you update only one group with a
new deployment
-) changing the value of a socket binding / jvm and determining which server-groups /
servers are affected
-) a deployment targeted to a single server - which would require to split the
server-group? not sure if we want to allow that, but we had some discussions with the
console team about that
Brian Stansberry wrote:
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?
I do like the diff update
actions - so that might be the best way moving forward with modifications. However
it's a bit unclear since the domain model is not really consistent at the moment.
appendDiff() seems to be the first thing which needs to be changed - since
AbstractModel.synchronize(AbstractModel model) is always doing
update.applyUpdate(AbstractModel model) on a List<AbstractModelUpdate<?>>. So
i guess we would need to have sort of hierarchical updates where each modification
maintains a list of updates for it's sub components? At least we should be able to use
this as a way to determine whether a profile / subsystem has changed or not.
Brian Stansberry wrote:
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).
Yes, i was thinking of a richer notion of references - especially since we
have a lot of elements which are referenced in the domain model. Where one part would be -
beeing able to validate the domain model as well as figuring out if a configuration update
needs to be pushed to e.g. server-group. Although i haven't really thought about
merging and activation - which is basically what the RefResolver is used for as well...
Re: renaming - i think this is an operation which does not really fit into appendDiff() /
calculateDiff() - if it's only a remove() and add() we would only know that that the
model is not valid anymore, however we would loose the information about the renaming
part.
I need to think about the actual management API a bit more though...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559596#559596]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5607
days inactive
5607
days old
jboss-dev-forums@lists.jboss.org
0 comments
1 participants
participants (1)
-
Emanuel Muckenhuber