[jboss-dev-forums] [Design of POJO Server] - Re: Controlling deployments via a barrier bean

[scott.stark@jboss.org]

"bstansberry at jboss.com" wrote : 
  | There would probably need to be some API change related to this, in order to allow mgmt tools to activate/inactivate sub-profiles. If we didn't want to allow external clients to do that, it could just be done via an spi that an activation policy would use.
  | 
  | AIUI, though, the detection of an @Singleton annotation or some other form of deployment-specific metadata is always done by a deployer; i.e. is not part of the profile service itself. (Waiting to be told I'm wrong ;) ) So you end up with a chicken and egg problem; you need to start deploying to find out a deployment is in an inactive sub-profile.  That's fundamentally what drove me to the idea of using dependencies.  I'd much prefer an approach where the deployers aren't even aware of content that isn't "activated".
The profile service does not look at deployment metadata, and there is no profile metadata corresponding to a jboss-activation.xml descriptor currently. I don't see how we would go from a bean/component level annotation to a subprofile membership. It seems we are driving at having an additional ActivationPolicyMetaData component for each deployment (maybe even component), but this still leaves a gap between specifying an annotation on a bean and identifying that the bean's deployment has a singleton component.

The profile service does not currently deal with makeup of a profile down to the component level. So what do we need for 1)? Its not completely true that:
anonymous wrote : 
  | 1) A scanner that populates the profile is a behavior of the basic profile service, but not of the full repository-based profile service. In the full version it's the DeploymentRepository impl itself that scans the filesystem for content.
  | 
in that you could still have an hasingleton scanner adding content to a profile regardless of what profile service implementation is in use. There should be a flag indicating that the deployment should not be a permanent part of the profile though. Is the APPLICATION_CLUSTERED phase going to be useful? Maybe this should be APPLICATION_TRANSIENT or some such to indicate a deployment that will not be remembered across restarts.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155721#4155721

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