[jboss-jira] [JBoss JIRA] (AS7-4091) Opimize organization and management of the JGroups subsystem

[Richard Achmatowicz (JIRA)]

     [ https://issues.jboss.org/browse/AS7-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated AS7-4091:
-------------------------------------

    Description: 
There are a number of areas where the JGroups subsystem is organizationally deficient:
- does not make use of ResourceDefinitions to (i) simplify the generation of DescriptionProviders and (ii) localize the definition of AttributeDefinitions
- handlers are in some cases written from scratch rather than subclassing helper handlers such as AbstractWriteAttributeHandler, AbstractAddStepHandler, AbstractRemoveStepHandler, etc.
- collections of services are defined monolithically, rather than in distinct units which makes stopping/restarting them error prone (c.f. CacheContainerAdd, CacheAdd install three or four services each with complex processing - stopping and restarting this in another handler is next to impossible)
- ServiceNames are not always easy to reconstruct   

These issues make maintenance of the subsystem hard. These matters can be helped by:
- making use of ResourceDefinitions
- defining for each service X a static method installX(context, operation, model) and removeX(context, operation, model) which can be made use of in installServices(context, operation, model) and removeServices(operation, context, model) 
- define the static method populate(), used to populate a model from an operation, which can be reused in populateModel(), creating describe operations, as well as other contexts
- define a static method installServices(context, operation, model) which can be used in performRuntime(), and in contexts where all services for a resource need to be stopped and restarted; similarly define removeServices(context, operation, model)
- make sure each ServiceName can be regenerated easily (c.f. regenerating JNDI names can involve model processing)


  was:
There are a number of areas where the Infinispan subsystem is organizationally deficient:
- does not make use of ResourceDefinitions to (i) simplify the generation of DescriptionProviders and (ii) localize the definition of AttributeDefinitions
- handlers are in some cases written from scratch rather than subclassing helper handlers such as AbstractWriteAttributeHandler, AbstractAddStepHandler, AbstractRemoveStepHandler, etc.
- collections of services are defined monolithically, rather than in distinct units which makes stopping/restarting them error prone (c.f. CacheContainerAdd, CacheAdd install three or four services each with complex processing - stopping and restarting this in another handler is next to impossible)
- ServiceNames are not always easy to reconstruct   

These issues make maintenance of the subsystem hard. These matters can be helped by:
- making use of ResourceDefinitions
- defining for each service X a static method installX(context, operation, model) and removeX(context, operation, model) which can be made use of in installServices(context, operation, model) and removeServices(operation, context, model) 
- define the static method populate(), used to populate a model from an operation, which can be reused in populateModel(), creating describe operations, as well as other contexts
- define a static method installServices(context, operation, model) which can be used in performRuntime(), and in contexts where all services for a resource need to be stopped and restarted; similarly define removeServices(context, operation, model)
- make sure each ServiceName can be regenerated easily (c.f. regenerating JNDI names can involve model processing)



    
> Opimize organization and management of the JGroups subsystem
> ------------------------------------------------------------
>
>                 Key: AS7-4091
>                 URL: https://issues.jboss.org/browse/AS7-4091
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 7.1.0.Final
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 7.1.2.Final
>
>
> There are a number of areas where the JGroups subsystem is organizationally deficient:
> - does not make use of ResourceDefinitions to (i) simplify the generation of DescriptionProviders and (ii) localize the definition of AttributeDefinitions
> - handlers are in some cases written from scratch rather than subclassing helper handlers such as AbstractWriteAttributeHandler, AbstractAddStepHandler, AbstractRemoveStepHandler, etc.
> - collections of services are defined monolithically, rather than in distinct units which makes stopping/restarting them error prone (c.f. CacheContainerAdd, CacheAdd install three or four services each with complex processing - stopping and restarting this in another handler is next to impossible)
> - ServiceNames are not always easy to reconstruct   
> These issues make maintenance of the subsystem hard. These matters can be helped by:
> - making use of ResourceDefinitions
> - defining for each service X a static method installX(context, operation, model) and removeX(context, operation, model) which can be made use of in installServices(context, operation, model) and removeServices(operation, context, model) 
> - define the static method populate(), used to populate a model from an operation, which can be reused in populateModel(), creating describe operations, as well as other contexts
> - define a static method installServices(context, operation, model) which can be used in performRuntime(), and in contexts where all services for a resource need to be stopped and restarted; similarly define removeServices(context, operation, model)
> - make sure each ServiceName can be regenerated easily (c.f. regenerating JNDI names can involve model processing)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira