[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by emuckenhuber
"bstansberry(a)jboss.com" wrote :
| Semi-OT, but one think that makes it hard to discuss is the term "profile" is overloaded.
|
Yes i also do think it's a bit overloaded - therefore i think a named group of deployments which belong together fits quite good :)
"bstansberry(a)jboss.com" wrote :
| 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.
|
I think also the term sub-profile seems to need some more definition.
Actually a sub-profile is just a profile - it is a notion which implies a relationship/dependency between two profiles.
What you actually can do with the profile then depends on the implementation itself.
"bstansberry(a)jboss.com" wrote :
| Yep, looking at Emmanuels XML examples last week...
One "m" is enough - just Emanuel ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206054#4206054
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206054
15 years, 10 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by emuckenhuber
"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#4206053
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206053
15 years, 10 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by bstansberry＠jboss.com
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.
Absolutely.
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 profile.
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 after "ejb3-runtime".
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206017#4206017
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206017
15 years, 10 months
[Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications
by alesj
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | This avoids also trivially allows you to avoid unpacking them again, since you can ask this cache.
| |
| ... since it solves (b), (c) and (d).
|
Actually this is not true by default.
This is as bad as replacing existing handler with temp.
We need a temp notion when asking for resources.
e.g. (your solution wouldn't know how to do this or would be inconsistent)
* deploy/ (the context root)
** myapp.ear (packed)
We then ask to temp this myapp.ear, which would create CacheInfo in deploy/'s context under myapp.ear path.
How do you then handle these two calls:
(1) root::getChildren()
(2) root::getChild("myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class")
(3) VFS::getRoot(new URL("${jboss.deploy}/myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class"))
I would expect for (1) not to use temp, otherwise I won't know when my original myapp.ear was deleted.
For (2) and (3) I would like to use all the existing temps I could get in order not to re-unpack something.
I see two solutions:
(a) keep two copies of the same context root; one would be fully temped, the other one not temped at all - and trying to synch them somehow
(b) when asking for resources, push in temp notion somehow (no idea right now, apart from ThreadLocal hack :-()
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206010#4206010
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206010
15 years, 10 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService (Repost)
by scott.stark＠jboss.org
"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 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 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
- 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
15 years, 10 months
[Design of POJO Server] - Re: The DeploymentManager and ProfileService
by scott.stark＠jboss.org
"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 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
15 years, 10 months