Community

Scott Stark wrote:

 

The following set of steps would each produce new sets of ManagedComponent property changes:

 

1. An initial domain.xml transforms the state of ManagedComponent properties from the new build state into some initial distribution state. There is a V1 repository of ManagedComponent property overrides.

2. embedded JON/JON updates provide a further set of changes. Where these properties intersect the metadata values of the domain.xml, it would have to be updated if we are going to allow direct editing of a server domain.xml. There is a V2 repository of ManagedComponent property overrides.

3. A rest client manipulates the current server domain metadata to push further updates. There is a V3 repository of ManagedComponent property overrides.

 

There is only one authoritative store of ManagedComponent property edits that the profileservice implementation manages. Any physical domain.xml is a filtered view of this store.

It definitely seems like domain.xml is a subset if we support the ability for frameworks to define managed components that are not part of our official domain.xml. This definitely includes runtime-only views, but it really could be anything.

There are some general questions I have relating to this (not necessarily expecting that we know the answer to these yet).

1. The current ManagedComponent model is flat, but the things we are talking about in domain.xml hierarchical. For example, JON will need the ability to define a data source at the domain, cluster, or node level. How should this be mapped? I suppose it could be a jmx-style attribute list on the ManagedComponent (type=Datasource, level=domain)
2. Are components created from deployments differentiated from those in the domain? As an example someone includes foo-ds.xml in a deployment. Do we implicitly map this as a node level concept in a domain?
3. Assuming the answer to the latter question in 2 is yes, what happens when JON updates this definition? In the past we talked about having it add the entry to the domain.xml, and subsequent restarts the domain would take precedent.
4. Are components not in the formal domain definition visible to other nodes in the domain? As an example someone creates FooDeployer, and FooDeployer creates FooComponent. I assume the answer to this question is no.
5. If the answer is no, how does a client know that these elements are not part of the "official" api?