Re: [jboss-dev-forums] [JBoss AS7 Development] - model updates and references
by Brian Stansberry
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&cont...]
13 years, 8 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - types of deployment errors and their handling
by John Bailey
John Bailey [http://community.jboss.org/people/johnbailey] replied to the discussion
"types of deployment errors and their handling"
To view the discussion, visit: http://community.jboss.org/message/559566#559566
--------------------------------------------------------------
As for item #1, I think there are a couple things to think about. I think subsystems/extensions, should be handled differently from deployments. I think if sub-system fails to activate based on some kind of exception thrown during activation (not a service start), I think the server should basically stop progressing, and basically log the information related to the problem. I just to don't think it makes sense for the server to continue if a subsystem failed. Deployments are a different story. I think the server should log the problem info, but continue to boot with other deployments. This is basically what is happening now. What is still needed is some ability to rollback any deployment specific services that may have been added to the batch prior to the failure occurring. The deployment already use MSC sub-batches, but the API does not have any options to rollback.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/559566#559566]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 8 months