"bstansberry(a)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
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 NOT 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
- 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'
View the original post :
Reply to the post :