[jboss-dev-forums] [Management Development] - Profiles in domain.xml

[David Lloyd]

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion

"Profiles in domain.xml"

To view the discussion, visit: http://community.jboss.org/message/546601#546601

--------------------------------------------------------------
To reply to an earlier message...
> Brian Stansberry wrote:
> 
> But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC.
> 
> We could say the DC has the ability to query the Servers to determine defaults, but besides being a can of worms it means the admin can't just start the DC and manipulate the domain configuration.
Jason had a good solution to this problem.  The configuration classes would know the defaults (which are in their corresponding XML schemas); by having the configuration classes separate from their projects (not unlike how the metadata project is intended to work, if I understand correctly), we can have the best of both worlds.  The domain controller (DC) can map the XML configuration into these classes at the domain level, and pass the object model on to the servers, which can then use that information directly to configure and/or override the deployed services.

Basically a configuration module for a given subsystem could have these responsibilities:
1. Register any XML namespace(s) it is associated with (on the DC)
2. Have the ability to validate & convert any relevant XML segments to the corresponding object model (on the DC)
3. Be responsible for configuring the subsystem they are associated with (on the server instance) via that subsystem's individual API
4. Knowing the management operations (queries and updates) available for a subsystem, and:1. Making the DC aware of them, and
2. Knowing how they affect the object model, so that
3. when the operation is sent to the DC and is passed on to the server instances, the DC and the server instances can all update their local domain models appropriately, to retain a consistent view.
4. Having an object representation of each management operation to effect the above.

5. Have the ability to convert the configuration they represent back into XML (on the DC)
6. Be aware of default values for any given configuration item (reflected in the schema as well)

This also would imply that the domain model passed to the server instances is actually a serialized representation.

An interesting issue this raises is how to deal with management operation failures in a server group.  In my view, the only sane way to handle it is to persist the change anyway, but make sure the admin client is aware of the problem.  This solution also enables consistent behavior between (a) making a change which affects a server which is not currently running and (b) making a change which fails to take effect for some reason.

Note that performing santiy checks and validation on the DC can minimize this (to give a simple example, the DC *should* be able to detect if you've assigned two services to the same port and are attempting to put those services in the same server group).

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/546601#546601]

Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2107]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20100607/51ca2347/attachment.html