[brian.stansberry]

The SBM case is an odd one; I basically used the MC schema to generate a bunch configuration pojos. So most of the injection there ends up just being injection of a configuration pojo. There is a JIRA to write a proper schema for the configuration stuff, which would end up as part of the domain.xml schema, but yeah, I could easily see it going away.

[jason.greene]

Brian Stansberry wrote:

Jason Greene wrote:

Scott Stark wrote:

I'm thinking that the profileservice ManagedComponent api is no longer relevant for our discussion. The fact that we introduced an indirection layer to allow for a stable metadata is only one part of what is needed. We need a well defined domain model that describes what the supported administration capabilities are for a given release. Now I'm thinking that the domain.xml is all that matters. Until a feature of the server has a representation in the domain.xml model, its not properly managable.

I totally agree. We should focus on the requirements, use-cases and the model/configuration itself. I also agree that something has to be in domain.xml for it to be truly managable. I kind of saw runtime management of components not in domain.xml as more of a stop-gap. However, it probably is easier to just focus on the domain model, and look at the non-classified runtime stuff later, if it is even relevant anymore.

Great. I'm a lot more comfortable with this approach. Multiple different management approaches coexisting in the same management API, some of which map back to domain.xml and some not -- yuck.

So do we agree that we should drop requirement 6? This would mean that if it's not in domain.xml you can't manage it.

[starksm64]

Yes. That allows for a simpler persistence and versioning implementation in addition to a simple representation of what the configuration of a domain is. This does require that we at least support what our current admin tools support in the initial switch to a domain.xml.

[brian.stansberry]

How about user deployments of well-understood containers (e.g. a war)?  That's not in domain.xml, but we provide management capabilities for such things. Although I could certainly see how we'd want domain.xml to be able to express the configuration information for a war, at least the jboss-specific stuff. In such a case, if a user updated the configuration of a war via a mgmt tool, we could persist the update back to domain.xml.

[starksm64]

All of the containers we are supporting need to be in the domain.xml model. Isn't our only supported mgmt tool at this point JON?

[starksm64]

For reference, here is the glassfish domain model structure:

The element hierarchy for the domain.xml file is as follows. To make the hierarchy more readable, elements having property as their last or only subelement are marked with a P, and the property subelements are not shown. Parent/child relationships between elements are shown, but not cardinality. For those details, see the element descriptions.

domain P
.    system-applications
.    .    application P
.    .   .    engine P
.    applications
.    .    application P
.    .   .    engine P
.    resources
.    .    jdbc-resource P
.    .    jdbc-connection-pool P
.    configs
.    .    config P
.    .   .    http-service P
.    .   .    .    access-log
.    .   .    .    request-processing
.    .   .    .    keep-alive
.    .   .    .    connection-pool
.    .   .    .    http-protocol
.    .   .    .    http-file-cache
.    .   .    .    http-listener P
.    .   .    .   .    ssl
.    .   .    .    virtual-server P
.    .   .    .   .    http-access-log
.    .   .    iiop-service
.    .   .    .    orb P
.    .   .    .    ssl-client-config
.    .   .    .   .    ssl 
.    .   .    .    iiop-listener P
.    .   .    .   .    ssl 
.    .   .    admin-service P
.    .   .    .    jmx-connector P
.    .   .    .   .    ssl 
.    .   .    .    das-config P
.    .   .    web-container P
.    .   .    .    session-config
.    .   .    .   .    session-manager
.    .   .    .   .    .    manager-properties P
.    .   .    .   .    .    store-properties P
.    .   .    .   .    session-properties P
.    .   .    ejb-container P
.    .   .    .    ejb-timer-service P
.    .   .    mdb-container P
.    .   .    jms-service P
.    .   .    .    jms-host P
.    .   .    log-service P
.    .   .    .    module-log-levels P
.    .   .    security-service P
.    .   .    .    auth-realm P
.    .   .    .    jacc-provider P
.    .   .    .    audit-module P
.    .   .    .    message-security-config
.    .   .    .   .    provider-config P
.    .   .    .   .    .    request-policy
.    .   .    .   .    .    response-policy
.    .   .    transaction-service P
.    .   .    monitoring-service P
.    .   .    .    module-monitoring-levels P
.    .   .    java-config P
.    .   .    .    profiler P
.    .   .    .   .    jvm-options
.    .   .    .    jvm-options
.    .   .    thread-pools
.    .   .    .    thread-pool P
.    .   .    system-property
.    servers
.    .    server P
.    .   .    application-ref
.    .   .    resource-ref
.    .   .    system-property
.    system-property

[emuckenhuber]

Jason Greene wrote:

The service binding manager should be obviated by the domain model, so there should be no need for injection overrides. Put another way, anything managed by domain.xml should not be allowed in some arbitrary beans.xml descriptor.

Yes, this is what i said in my other post about the domain model some months ago. And again service-binding-manager was just an example. It is a general problem applying overrides to jboss-beans.xml which i tried to describe.

[emuckenhuber]

Emanuel Muckenhuber wrote:

Yes, this is what i said in my other post about the domain model some months ago. And again service-binding-manager was just an example. It is a general problem applying overrides to jboss-beans.xml which i tried to describe.

But i think we can just ignore that for now - i'll keep it in mind and will follow up on this later

[starksm64]

I understand a bit more of what Emanuel as raising as a concern about IOC, and I started this thread to discuss the implications on the profileservice SPI and implementation.

https://community.jboss.org/thread/150461

[brian.stansberry]

As a follow-up to our discussions last week, I've created a wiki page that incorporates many of the concepts we discussed. Comments/edits are very much appreciated. Next I'll get Jason's requirements document page updated to reflect the additional requirements we discussed.

[dmlloyd]

Let's try to come to agreement on the non-agreed-upon terms listed on http://community.jboss.org/wiki/DomainManagementModelDesign.

[starksm64]

This is what I would propose for the profile and related terms:

• Profile: The set of virtual deployments that are included in the server configuration along with the deployment repository reference. A profile consists of one or more subprofiles that define the bootstrap deployments, deployers, core deployments, user deployments, dynamic deployments (hot deployment).
• Subprofile: A collection of virtual deployments that describe a repository virtual file, as well as the capabilities and requirements of the deployments.
• Capability: A named set of properties (essentially the OSGi capability notion).
• Requirement: An expression of the capabilitiy properties that are needed in order for a deployment to be made runnable.
  

[emuckenhuber]

So a DomainControllerProfile could then be a sub-profile providing the capabilities for a server to act as DomainController?

[dmlloyd]

The terms I suggest are:

• Server Manager (formerly NodeAgent) as the module which is responsible for coordinating with the Domain Controller to control the lifecycle of Server processes, the distribution of deployments from the Domain Controller to the Server instances, and the management of the Installed Image
• Server Manager Process as a JVM instance which runs the Server Manager exclusively
• Formalize Brian's Installed Image term as-is
• Formalize Brian's Domain Controller term as-is

[jason.greene]

David Lloyd wrote:

The terms I suggest are:

• Server Manager (formerly NodeAgent) as the module which is responsible for coordinating with the Domain Controller to control the lifecycle of Server processes, the distribution of deployments from the Domain Controller to the Server instances, and the management of the Installed Image
• Server Manager Process as a JVM instance which runs the Server Manager exclusively
• Formalize Brian's Installed Image term as-is
• Formalize Brian's Domain Controller term as-is

I think server manager is a much better name, as we don't have a "node" construct in the topology. The more explicit definitions of domain controller and install image match my understanding of the discussions we had in Westford. So yeah I agree with all of these.