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

[bstansberry@jboss.com]

Thanks guys, for the input. :)  My apologies, I opened this thread a couple hours before leaving on a trip where it turned out I had no chance for e-mail. I'll respond bit by bit as I digest.

"adrian at jboss.org" wrote : 
  | Short term for now, I'd just go with extending the hot deployment profile service to allow
  | some kind of barrier service like Brian describes to add/remove a sub-profile dynamically.
  | 
  | I'm not sure it needs to be as complicated as Brian describes though?
  | i.e. messing around with dependencies
  | The hasingleton scanner should just respond to the elected/de-elected event
  | by adding/removing its profile to/from the profile service.

This is essentially what's there now.  Discovered last week that something is broken with it, but since it has a few flaws I wanted to focus on a more long-term replacement rather than just a quick fix. The flaws:

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.

2) The distinction betweens what's in a profile and how it's reflected in the runtime. If the profile service on a non-master node isn't aware at all of a set of deployments, those deployments can't be managed (e.g. some piece of metadata changed), at least not directly on that node.

3) Can't handle the fine-grained metadata driven approach you describe in your '@Singleton policy="DefaultPartitionSingleton"' example.

Properly dealing with #2 and #3 could possibly be deferred; i.e. use a short term approach for 5.0.0. But AIUI, ability to use the full profile service is a requirement for 5.0.0 though, so I'd need to solve #1. On the farming thread Scott and I agreed last week that a clustered DeploymentRepository would need to have a clustered comm resource (JGroups Channel) available to it, so it's possible its internal scan logic could have the ability to respond to an elected/unelected event and add/remove sub-profile content. But that could end up being a fair amount of work and if the work will just be thrown away when I solve #2 and #3, I'm reluctant to do it that way.

I need to better understand what Scott's driving at with the discussion of DESCRIBE, DESCRIBE_CLUSTERED, DESCRIBE_SINGLETON and how that solves the issue where we "(r)eally we don't want the unelected singleton beans to be exposed as available for installation as runtime components."  Thanks, Ales for the links to the alias stuff; found where that's used.

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

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