On 1/11/11 4:23 AM, Heiko Braun wrote: (I'm reordering your questions a bit to let me make a more coherent response.) This is the integration code that implements the AS 7 management SPIs and knows how to talk to the subsystem's internal managment API. See below. The best place to start looking to see how we see this working is: https://github.com/bstansberry/jboss-as/tree/detyped2/controller/src/main... (Note that classes named NewXXX are meant to be renamed to XXX once we shift over to the detyped representation of the management model.) A module that extends the core capabilities of the AS needs to implement the NewExtension interface. So all the existing subsystems like JMX, web, osgi, messaging implement Extension. When we start the NewExtension we pass NewExtensionContext to initialize(). The extension can use that interface to register the subsystems it exposes (usually just one). You can follow the interfaces to see what goes on. Basically, the subsystem must expose a tree-structured management model. Each node in the tree can have attributes and operations. The subsystem registers handlers for all operations it exposes. Those handlers are what would delegate back to whatever internal management API the project exposes. Notifications -- these are a glaring hole in the SPI. We need to add them in. I think it should be relatively straightforward. Notifications would have an address in the tree (like everything else), a String name, and a detyped payload. I'm not sure what you're asking, but I'll answer with something hopefully useful. :-) An extension interacts with AS 7 at two levels: the domain (running inside a DomainController or HostController) and the server (running inside a standalone or domain-managed server). Inside the DomainController/HostController, the interaction is pretty simple. The DC maintains a data structure representing the persistent domain configuration (i.e. what's in domain.xml). An extension needs to provide operation handlers that can update it's portion of that data structure. Each server also maintains an equivalent data structure that represents its configuration. That's either a) in domain mode, a non-persistent view of the translation from domain.xml + host.xml to the server's configuration, or b) in standalone mode, a representation of the persistent standalone.xml config. (The data structure is the same in either case, and the extension doesn't care whether it's domain mode or standalone mode.) On the server, an extension needs to provide operation handlers that can update it's portion of that data structure. *Plus*, those handlers need to be able create/remove/interact with the actual runtime services the extension supports. (E.g. read and return some metric, change the size of a thread pool, start a new connector, etc.) -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

On 1/12/11 2:21 AM, Heiko Braun wrote: LOL. I knew that was the case. The rest of all that was kind of a draft for me to post on some wiki somewhere some day. :) -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

This is what I expected. Thanks for the clarification. /Ike On Jan 11, 2011, at 4:27 PM, Jason T. Greene wrote: