[jboss-dev-forums] [Management Development] - domain.xml work

[Emanuel Muckenhuber]

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion

"domain.xml work"

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

--------------------------------------------------------------
I think the mapping onto profileservice itself should be quite separate from the domain model

So in a nutshel the operations related to profileservice should be not more than:

a) createNewDeployment()
b) addRequirement()
c) addCapability()
d) addMetaDataOverrideFragment()
e) addConfigurationFragment()

a,b,c should be fairly easy - since this is what a profile does.
d) would define a meta-data override of a existing deployment - like <component-ref />
e) is something where we don't have a notion for it now. This would be a service configuration e.g. <connector /> which does not neccearily create a bean nor deployment. Maybe this just maps to a injection of the metadata from the repository.

(d) and (e) would populate the unprocessed domain.xml fragements to a MetaDataRepository in a domain scope. This is needed since we have to distribute this to the whole domain - so we cannot do system property replacement there, as system properties in some cases could be just for a single instance/node e.g. ports-01.
Additionally we also need to populate the MetaDataRepository with default values, those have to be kept separate until the point we actually do transformations/injections of the domain metadata itself. Basically to reduce the size of the domain.xml to configuration overrides - additionally we can compare and only store changed values back to the domain.xml

> Scott Stark wrote:
> 
> The relatively easy part is deciding what features we  want to support via the model. The issues to resolve are how to:
> 1. Map this metadata onto the admin API of the profileservice. In  general the domain.xml is a subset of the full metadata the service  supports. The ManagedComponent view of the deployment metadata is the  full featured configuration.
> 2. Provide a plug in to handle the  mapping of the domain.xml metadata onto the ManagedComponent associated  with the domain.xml element namespace. Currently the ManagedComponent is  a view that is generated after deployment.
> 3. Deal with the different mechanisms for producing the runtime  components from metadata. Some layers are using BeanMetaDataFactorys,  jboss-managed plugins, custom deployers to manipulate metadata. Pulling  in the domain.xml element override at the correct phase in the  deployment chain is an issue.
> 4. Dealing with rollbacks of the domain.xml if we allow direct  editing of the a domain.xml file. If the domain.xml is essentially a  subset of admin edits of the available ManagedComponents, a rollback  needs to write out a revised domain.xml that corresponds to the previous  subset view.
> 

I think (2) is where we should start - where each domain.xml fragment could map to e.g. a ManagedComponent. Based on this we can do the association between the domain.xml override and default values/additional handling and value transformation. We can also create dependencies on the actual profile handling this namespace. For metrics and other runtime views, we would need to do some merging of MOs once the beans are available and the mgtView is getting loaded.

(3) is the tricky part of overriding. Most probably this should be plugable and additional handler would be linked with the domain fragment itself.

However if we differentiate between: a), d), e)  - this also gets easier, since we know what to do.
for createNewDeployment() it would mean that the fragment will be a predetermined attachment e.g. creating a DataSource, ThreadPool.

addMetaDataOverrideFragment() is the most expensive operation since we need to scan all attachment to identify a <component-ref /> and update the metadata passed through the deployer.

with addConfigurationFragment() you should most probably just ask the repository for the metadata itself - where we just do merging default values and value transformation (system property replacement, ports) - so you can either decide to reuse the domain metadata directly or transform it yourself.

(4) mostly relates to the persistence part. Where we need a way to compare and determine which values changed. During runtime this is easier since the fragments would correspond to a ManagedComponent. Where the persistence itself is the most critical piece.

I don't clearly see how preserving comments would fit into a static meta data model. Maybe we can reuse the SchemaBinding to partially update the xml. So not marshalling the whole xml, just take what changed and apply it to the existing xml or something else? This is something we need to validate and check asap and then see how this fits into what you have started.

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

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

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/20100401/095b950d/attachment.html