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

[adrian@jboss.org]

I think as far as backwards compatibility goes Brian's approach is roughly correct,
but it should NOT be using the MainDeployer directly.

It should be based on a (sub-)profile.

If you look in broad brush terms, the profile service is made up of two components

1) A client side api that lets you define what a profile is
2) A server side that implements that profile at runtime

For the current default profile (hot deployment) that means three pojos that know how 
to scan three sets of directories/urls (bootstrap/deployers/deploy) 
which are the three sub-profiles that make up the profile.

There should be a way to add extra (sub-)profiles e.g. hasingleton, jbossmq, etc.
that could be based on normal, singleton or farm semantics.
These are just implementation details of how the server side profile is implementated.

In practice, these subprofiles are not implemented in such a flexible way
with the scanners being hardwired along with the subprofiles they represent
and a subprofile is always active.

In terms of where we want to get to in the profile service and metadata in
general, it should be possible using a management console to say
I want this sub-profile, deployment, service, etc. to be a singleton in a given
partition.

I'd say partition is too low level since what you really want is some election policy
which could be generalised beyond the hasingleton notion to some activation policy.
e.g. you activate a deployment based on a timer rather than clustered failover election

By taking a metadata approach, users can also programme this explicitly
without having to use the management console directly.
e.g. I add a META-INF/jboss-activation.xml to describe how/when I want
this deployment starting/stopping

At the service/pojo level this would probably be an annotation

  | <bean name="Whatever" ...>
  |    <annotation>@Singleton policy="DefaultPartitionSingleton"<annotation/>
  | ...
  | 
Which could also be applied via the scoped metadata if you want to
externalise it from the main descriptors in the management console/profile service case.


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.

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

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