For the YES, this is my quick overview. Again my concern is having suffucient structure to be able to evolve the domain model, but a sufficiently limited scope in terms of content to be able to have an implementation.
bindingservice.beans - All of the containers/services intersected by this need associated entries in the domain model such that this configuration can be dropped.
login-config.xml,
hornetq-*.properties,
jbossws-*.properties,
jmx-console-*.properties - definitely need a domain model for security stacks and users.
properties-service.xml - Need to define how jvm, system properties are pulled in to control bootstrap and affect other configurations that reference properties.
jboss-logging.xml - I guess this is pretty much pulled into the domain?
*{container}.deployer/.xml,
deploy/hornetq/hornetq-configuration.xml,
thread-pool-j-b.xml - In general, I think we need the following common mappings for containers in the domain metadata:
- thread pools
- clustering groups
- transport stacks
- instance pools
legacy-conf-jboss-service.xml - shouldn't this just be eliminated?
hsqldb-ds.xml, any other resource factory - We need a server resources factory configuration model forthe various standard types.
mod_cluster.sar,
jboss-cache-manager.sar,
jgroups-channel-factory.sar,
deploy-hasingleton-jboss-beans.xml,
farm-deployment-j-b.xml,
hajndi-j-b.xml,
hapartition-jboss-beans.xml, - Need a cluster domain metadata model
jbossweb.sar/server.xml,
ejb3-connectors-j-b.xml,
remoting3-j-b.xml,
remoting-j-b.xml,
xnio-provider.jar - Need a connector/transport domain metadata model
jacorb.properties,
mail-service.xml,
monitoring-service.xml,
schedule-manager-service.xml,
scheduler-service.xml,
juddi-service.sar,
snmp-adaptor.sar,
uuid-key-generator.sar,
monitoring-service.xml,
*-activator-j-b.xml, - I don't see these as being in scope for an initial release