4:24 p.m.
Richard Achmatowicz created AS7-4090:
----------------------------------------
Summary: Opimize organization and management of the Infinispan subsystem
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
Project: Application Server 7
Issue Type: Task
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Fix For: 7.1.2.Final
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)
--
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
4:24 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz reassigned AS7-4090:
----------------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
5:50 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4090:
------------------------------------------
Implemented CacheAdd.installRuntimeServices() and CacheAdd.removeRuntimeServices() which
allow reuse of service installation and removal in CacheAdd.performRuntime() and
CacheRemove.restoreServices().
Because each cache add operation (LocalCacheAdd, InvalidationCacheAdd, ReplicatedCacheAdd,
DistributedCacheAdd) is a subclass of CacheAdd, these methods were not implemented as
static methods.
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
5:52 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz edited comment on AS7-4090 at 3/15/12 6:51 PM:
-------------------------------------------------------------------
Implemented CacheAdd.installRuntimeServices() and CacheAdd.removeRuntimeServices() which
allow reuse of service installation and removal in CacheAdd.performRuntime() and
CacheRemove.restoreServices().
Because each cache add operation (LocalCacheAdd, InvalidationCacheAdd, ReplicatedCacheAdd,
DistributedCacheAdd) is a subclass of CacheAdd, these methods were not implemented as
static methods.
Also added test case OperationSequencesTestCase to test that combinations of add and
remove operations work correctly in sequence.
was (Author: rachmato):
Implemented CacheAdd.installRuntimeServices() and CacheAdd.removeRuntimeServices()
which allow reuse of service installation and removal in CacheAdd.performRuntime() and
CacheRemove.restoreServices().
Because each cache add operation (LocalCacheAdd, InvalidationCacheAdd, ReplicatedCacheAdd,
DistributedCacheAdd) is a subclass of CacheAdd, these methods were not implemented as
static methods.
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
4:04 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4090:
------------------------------------------
Implemented CacheContainerAdd.installRuntimeServices() and
CacheContainerAdd.removeRuntimeServices() which allow reuse of service installation and
removal in CacheContainerAdd.performRuntime() and CacheContainerRemove.restoreServices().
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
4:16 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4090:
------------------------------------------
There was a general problem encountered when implementing performRuntime() and
restoreServices() using the existing methods installRuntimeServices() and
restoreServices().
The problem is that the portions of the model available when calling performRuntime() and
recoverServices() are not the same - when we call recoverServices(), the cache
container/cache portions of the model have already been removed, and we cannot navigate to
them using Resource.Tools.readModel(context.readModel(<some address>)), as was
required in the initial implementations of installRuntimeServices() and restoreServices().
The model instead needs to be obtained from the ModelNode model parameters passed to
recoverServices().
Therefore, installRuntimeServices() had to be refactored so that we pass in the correct
models according to the context we are executing in, as parameters, and we don't look
them up based on navigation from within the method as before.
So, of:
{noformat}
installRuntimeServices(OperationContext context, ModelNode operation, ModelNode model,
ServiceVerificationHandler handler,
List<ServiceController<ServiceController<?>> newControllers) {
...
// look up the models for container and cache
..
}
{noformat}
we instead do
{noformat}
// look up the models for container and cache
installRuntimeServices(OperationContext context, ModelNode operation, ModelNode
containerModel, ModelNode cacheModel, ServiceVerificationHandler handler,
List<ServiceController<ServiceController<?>> newControllers) {
...
}
{noformat}
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
4:18 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz edited comment on AS7-4090 at 3/20/12 5:17 PM:
-------------------------------------------------------------------
There was a general problem encountered when implementing performRuntime() and
restoreServices() using the existing methods installRuntimeServices() and
restoreServices().
The problem is that the portions of the model available when calling performRuntime() and
recoverServices() are not the same - when we call recoverServices(), the cache
container/cache portions of the model have already been removed, and we cannot navigate to
them using
{noformat}
Resource.Tools.readModel(context.readModel(<some address>))
{noformat}
as was required in the initial implementations of installRuntimeServices() and
restoreServices(). The model instead needs to be obtained from the ModelNode model
parameters passed to recoverServices().
Therefore, installRuntimeServices() had to be refactored so that we pass in the correct
models according to the context we are executing in, as parameters, and we don't look
them up based on navigation from within the method as before.
So, of:
{noformat}
installRuntimeServices(OperationContext context, ModelNode operation, ModelNode model,
ServiceVerificationHandler handler,
List<ServiceController<ServiceController<?>> newControllers) {
...
// look up the models for container and cache
...
}
{noformat}
we instead do
{noformat}
// look up the models for container and cache
...
installRuntimeServices(OperationContext context, ModelNode operation, ModelNode
containerModel, ModelNode cacheModel, ServiceVerificationHandler handler,
List<ServiceController<ServiceController<?>> newControllers) {
...
}
{noformat}
was (Author: rachmato):
There was a general problem encountered when implementing performRuntime() and
restoreServices() using the existing methods installRuntimeServices() and
restoreServices().
The problem is that the portions of the model available when calling performRuntime() and
recoverServices() are not the same - when we call recoverServices(), the cache
container/cache portions of the model have already been removed, and we cannot navigate to
them using Resource.Tools.readModel(context.readModel(<some address>)), as was
required in the initial implementations of installRuntimeServices() and restoreServices().
The model instead needs to be obtained from the ModelNode model parameters passed to
recoverServices().
Therefore, installRuntimeServices() had to be refactored so that we pass in the correct
models according to the context we are executing in, as parameters, and we don't look
them up based on navigation from within the method as before.
So, of:
{noformat}
installRuntimeServices(OperationContext context, ModelNode operation, ModelNode model,
ServiceVerificationHandler handler,
List<ServiceController<ServiceController<?>> newControllers) {
...
// look up the models for container and cache
..
}
{noformat}
we instead do
{noformat}
// look up the models for container and cache
installRuntimeServices(OperationContext context, ModelNode operation, ModelNode
containerModel, ModelNode cacheModel, ServiceVerificationHandler handler,
List<ServiceController<ServiceController<?>> newControllers) {
...
}
{noformat}
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
4:22 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4090:
------------------------------------------
Added in a Byteman-based test case called OperationSequenceTestcase.testRemoveRollback()
for testing rollback of the remove operation.
This test case uses a Byteman rule to inject a "fault" into the
CacheContainerRemove.performRuntime() operation - in fact, we inject the line of code
{noformat}
context.setRollbackOnly()
{noformat}
in the execution of performRuntime() which forces a rollback of the otherwise correctly
executing method implementation. The test case checks that (i) a failure results anmd (ii)
that the expected services are reinstalled correctly and appear in the service registry.
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
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 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)
--
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
3:02 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry updated AS7-4090:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
(was: 7.1.2.Final (EAP))
Component/s: Domain Management
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
Project: Application Server 7
Issue Type: Task
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 7.2.0.Alpha1
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)
--
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
12:05 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4090:
------------------------------------------
Starting the conversion of this subsystem to resources.
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
Project: Application Server 7
Issue Type: Task
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 7.2.0.Alpha1
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)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:46 p.m.
[
https://issues.jboss.org/browse/AS7-4090?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-4090:
------------------------------------------
Conversion is finished. Some points follow.
Resource Hierarchy
In order to facilitate sharing of resource attributes between different cache types, a
hierarchy of ResourceDefinitions was created which looks like this:
SharedCacheResource extends ClusteredCacheResource extends CacheResource extends
SimpleResourceDefinition
LocalCacheResource extends CacheResource
InvalidationcacheResource extends ClusteredCacheResource
ReplicatedCacheResource extends SharedCacheResource
DistributedCacheResource extends SharedcacheResource
In order to accompany this sharing with sharing of bundle entries, had to implement a
custom ResourceDescriptionResolver which registers all shared attributes and does a
separate lookup when the attribute description is requested. This works but can probably
be improved.
JDBC stores and complex attributes
The JDBC stores require table definitions, such as binary keyed table, string keyed table
and mixed keyed table. These are not broken down into resources, and instead are held and
manipulated as complex attributes (see STRING_KEYED_TABLE, BINARY_KEYED_TABLE,
MIXED_KEYED_TABLE AttributeDefinitions).
Optional 'properties' parameter on add
In the case of resources which can define properties as sub-elements (such as cache
stores), the add() operation, in addition to taking the immediate attributes of the
resource, can also take an optional properties attribute which is a list of properties.
This list will be processed in the add() command and the nested property resources will be
created. This is a shorthand and property resources can be created in the ususal way.
Test cases
I added a super class OperationTestCaseBase to provide common definitions used in
OperationsTestCase and OperationSequencesTestCase, as well as starting to fill out testing
coverage for each resources attributes. This needs to be continuted.
Opimize organization and management of the Infinispan subsystem
---------------------------------------------------------------
Key: AS7-4090
URL: https://issues.jboss.org/browse/AS7-4090
Project: Application Server 7
Issue Type: Task
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 7.2.0.Alpha1
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)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4465
days inactive
4697
days old
10 comments
2 participants
participants (2)
-
Brian Stansberry (JIRA) -
Richard Achmatowicz (JIRA)