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&...]