[jboss-dev-forums] [Design of POJO Server] - Re: Profile Service api

[adrian@jboss.org]

"scott.stark at 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#4192185

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