"scott.stark(a)jboss.org" wrote : Right, there is no notion of sub-profiles. How
would the HASingletonDeploymentScanner be changed, deployment phases would be distinct
sub-profiles that register with the ProfileService?
|
When I initially suggested the profile-service I imagined it as something like
(assuming a more modern maven repository)
Pseudo xml as usual :-)
| <profiles>
| <profile name="default">
| <source
type="Maven">http://repository.jboss.com/maven2</source>
| <source
type="Maven">http:/repository.acme.com/maven2</source>
| <sub-profile>naming</sub-profile>
| <sub-profile>transaction</sub-profile>
| <sub-profile>jms</sub-profile>
| <sub-profile>ejb3</sub-profile>
| <deployment>MyApp1</deployment>
| </profile>
| </profiles>
|
The "deployment phase" if it is really a useful concept at all
would be included within the profile definition, e.g.
| <profiles name="ejb3">
| <profile name="ejb3-deployer" phase="deployers">
| <source
type="Maven">http://repository.jboss.com/maven2</source>
| <deployment>jboss-jpa-deployer</deployment>
| <deployment>jboss-ejb-deployer</deployment>
| </profile>
| <profile name="ejb3-runtime" phase="deploy">
| <source
type="Maven">http://repository.jboss.com/maven2</source>
| <deployment>jboss-ejb3.beans</deployment>
| </profile>
| </profiles>
|
I say it is probably not really useful because one could assume
that the ejb3-deployer sub-profile must be fully deployed before
ejb3-runtime is deployed.
Basically, this is back to the original intention of the profile service
which is to just provide a list of deployments you want deployed
no matter where they come from.
The handling of overrides from the management console
to these original deployments is a different concern
(although you could imagine the above pseudo xml containing
xml elements that also include overrides from your own repository).
I understand there are complications if you want the original deployments
to be hot deployable (or don't if you set some lockdown flag after you've
used the management console to edit them).
The most complicated of these being patching where you try to merge
the diff of the original into the config managed by the console.
In terms of the farming (or the hot deployment prototype),
this is just another way of producing a list of original deployments.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192185#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...