[jboss-dev-forums] [Design of POJO Server] - Re: The DeploymentManager and ProfileService

[scott.stark@jboss.org]

"bstansberry at jboss.com" wrote : 
  | Are two different concepts getting mixed here?
  | 
  | 1) Statically defined vs. dynamic profiles. In the former all the contents of the profile are explicitly listed, in the latter a (set of) root URLs is defined and whatever is under those roots becomes part of the profile. The former is largely used to define the server's JBoss-provided capabilities, the latter provides the "drop a war in deploy/ and it gets deployed" functionality for users.
  | 
  | 2) Hot deployment == we monitor the profile's contents and if a file changes we redeploy. This applies to both static and dynamic profiles. For dynamic profiles this also includes detecting new items under the root URL and the removal of items under the root URL.

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. I would agree that a set of root URLs defines a profile. I still think that is a carry over from our old notion. We should be able to define which deployments in the deploy directory for example are actually part of the profile. 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.

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. 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'.

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

I'm working on the later 2 as I expect that these will most impact the need for a change beyond the current 'deploy', 'bootstrap', 'deployers' notions.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206005#4206005

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206005