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

[adrian@jboss.org]

"bstansberry at jboss.com" wrote : 
  | 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".

That's more long term (i.e. a proper implementation ;-). 
The more fine-grained stuff involves defining some callbacks that are triggered by some policy.

e.g. You might have (or it could be annotation based):


  | public interface Activation
  | {
  |    void activate();
  |    void deactivate();
  | }
  | 

But it will depend upon what you are doing on how the object gets registred with
the policy.

The simplest case might be something like;

  | @Activatable(policy="SomeNameInTheMC")
  | public MyPOJO
  | {
  |    @Activate
  |     public void method1();
  | 
  |     @Deactivate
  |     public void method2();
  | }
  | 
  | The registration can then be handled using something similar to the @JMX
  | handling. i.e. you write a lifecycle-install handler
  | that looks for the annotation/interface and does the relevant registrations.
  | (This requires another interface, i.e. ActivationPolicy or Activator)
  | 
  | More complicated would be an MDB that you want to start/stop delivery on some 
  | kind of schedule.
  | That would involve registering the MDB container (or some activatable extension)
  | with the activation policy at deployment and wait for the callbacks.
  | Of course if the MDB container is just a POJO then it is the same as above.
  | 
  | The activation of the sub-profile also be the same thing. 
  | The de/activation methods just to talk to the profile service.
  | 
  | 
  |   | @Activatable(policy="HASingletonDefaultDomain")
  |   | public class ProfileActivator
  |   | {
  |   |    private String subProfileName;
  |   |    @Inject
  |   |    private ProfileService profileService;
  |   | 
  |   |    @Activate
  |   |    public void activate()
  |   |    {
  |   |       profileService.deployProfile(subProfileName);
  |   |    }
  |   | // etc.
  |   | 
  | We could also get more complicated and with activation requiring multiple policies
  | and logic to decide whether something is active.
  | This probably ties in with what Ales was doing with the JBoss Rules integration in
  | the MC, but that's obviously in the 5% of use cases. ;-)

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

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