Part of what needs to come out of this discussion is how to organize the information; i.e. don't just assume a simple single "type" deployment; think about ears, wars that package ejbs etc. Re: overriding descriptors, we've previously supported that in places via JMX; i.e. some of our mbeans expose attributes that have the effect of overriding some value that came from a deployment descriptor. We can still do that; IMO we should. The management metadata exposes whether an attribute is stored to CONFIGURATION or RUNTIME, so the effect is visible. The resources that expose those kinds of attributes don't have to map 1:1 to some deployment descriptor though. For example if we had an attribute that lets the user change the session timeout for a webapp it doesn't have to be in a resource that models web.xml. It can be in a resource that models the session manager, a la the mbean we've always had. I don't want to worry about persisting deployment descriptor overrides back to domain/standalone.xml at this point; i.e. any attributes that override deployment settings should be Storage.RUNTIME. On 5/5/11 5:16 AM, Heiko Braun wrote: -- Brian Stansberry Principal Software Engineer JBoss by Red Hat