I think we're on the same page, but I'll respond in detail in case I'm wrong.
"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.
Semi-OT, but one think that makes it hard to discuss is the term "profile" is
overloaded. There's an overall profile that's conceptually simple/ easy to explain
as an abstraction of the old "all" "default" "minimal"
config notion. Then we have elements of a profile that we're calling sub-profiles, but
which are currently described in xml via a "profile" element and modelled in
code as implementations of the Profile interface.
anonymous wrote : 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.
No, by itself a set of root URLs doesn't define a profile. In the sense I was talking
about, a collection of root URLs is one way of defining the 2nd of your list of things
that define a profile: the collection of deployments.
anonymous wrote : We should be able to define which deployments in the deploy directory
for example are actually part of the profile.
Agreed. And in practice I imagine most of the deployments JBoss itself provides will be
specified this way. And maybe, in some setups, all the end-user deployments as well. But
as a particular implementation of a subprofile it should also be able to define that the
"xyz" dir is a location where you can copy a jar and it will be part of the
anonymous 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.
I still see those as two different although related things. Perhaps from the point of view
of an SPI it doesn't matter. I'd think management tools would care though: can the
tool add or remove content from this subprofile? Can the tool update existing content?
Will the repository itself detect and allow content added or removed not via the
management tool? Will the repository itself detect updates to existing content? This is
all information that should be exposed.
anonymous 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?
I'd think you'd have common/deploy which basically looks like server/all/deploy,
and then server/xxx/deploy would be empty but monitored for changes. That's just a
stock config though. People could configure things however they wish.
anonymous wrote : 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'.
Yep, looking at Emmanuels XML examples last week, the "deploy" after
"deployers" notion had already somewhat broken down (IMO correctly). E.g. he had
a jboss-web.profile which contained a "jboss-web-deployers" subprofile and and
an "jboss-web-runtime" subprofile. But within the overall sequence both come
View the original post :
Reply to the post :