"scott.stark(a)jboss.org" wrote : | For me a dynamic profile and hot deployment are a related capability, so we need to define what a profile is to agree on where dynamic behavior comes in. | Hmm yeah we might want to have a Profile and a MutableProfile interface. "scott.stark(a)jboss.org" wrote : | So I see a profile as having: | - A key which provides a name, some unused hierarchy to an admin domain | - a collection of deployments. Whether or not this can change as well as the deployments themselves can change is what I would call dynamic. | - an optional collection of admin edits to apply to the deployments | - a logical repository that contains the deployments and edits. Right now this is not explicit at the profile api level. The DeploymentManager and ManagementViews require it for their implementation. | In a nutshell a Profile is a group of deployments (no matter where they come from). So it can be a static one, based on file scanning we have now or any other source. I also introduced relationships between profiles - now thinking of it, we might want to have this as implementation detail. In general this is not explicitly required and it can be different for each implementation. Furthermore ProfileService / Profile should not or must not know about the actual runtime deployment. I think this is very important, as the real deployment needs to be done by the deployers (that's why we have them :) Therefore also the abstraction of a ProfileDeployment. "scott.stark(a)jboss.org" wrote : | If we completely abstract out the deployment and admin content into a deployment repository, then I can see a differentiation between a dynamic profile that is one define by root urls against the deployment repository vs a profile that allows modifications to both deployment collection make up and content changes. | One thing i don't like about the current implementation is that a profile is more defined over it's DeploymentRepository than it is defined by itself (the actual profile). Well i mean the implementation is not a big deal, just want to say that when talking about the definition of a Profile, a DeploymentRepository should be optional. On the other hand this is actually the main point of this thread. Basically how the DeploymentManager gets access to the low level source of a mutable profile. I'm not planning to change this yet - just an idea to think about :) "scott.stark(a)jboss.org" wrote : | With the new subprofiles, we really should not be shipping anything in the deploy directory, or we should have deploy/apps be what is monitored for changes? If there is a deployment repository notion, even urls are an implementation notion, and 'deploy' is really an alias for a class of deployments that depend on the 'bootstrap' and 'deployers'. | Yes that's where we are definitely are heading for! I think we might ship a empty deployers directory (where the user can put his own deployers) and a almost empty deploy directory - where we just have things like ROOT.war, jmx-console.war. So optional things which you can just delete. But in the end that would not change anything about PS anymore :) "scott.stark(a)jboss.org" wrote : | I don't think there is a correct definition, just what is going to map best to our usecases and let us get to an spi that is going to work for the several server configurations we know we want to deal with: | - jbossas5 EE5 style | - jbossas6 EE6 style | - testsuite configurations | - embedded | - junit testing | Hmm yes - although the canonical server is the most important requirement to enable all this. IMHO a good integration into jboss-test, server-manager are needed before we can move on updating the testsuite and the distribution. In the meantime we can just base this on a all config. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206053#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...