[
https://issues.apache.org/jira/browse/ACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff updated ACE-347:
--------------------------------
Description:
The Managent Agent was made "self-contained" in ACE-232 but there are still
some concerns with regard to complexity and functionality. This issue deals
with restructuring the Managent Agent code to make it easier to maintain,
configure and extend. Also see ACE-324 / ACE-324.
Management Agent code:
The MA implementation is setup very modular and it assembled mainly based on CM
factories. Maybe a little too much. The code is scattered over projects making
it hard to maintain and it is violating visibility rules to implementation
classes which is nasty in bndtools.
-> We should centralize the 'dedicated' MA code in the MA project allowing us
to clean up a lot of projects.
Management Agent config:
The fact that we can theoretically reconfigure these services at runtime
through CM does not add much more then a runtime dependency on a CM impl. There
is an obvisou catch-22 in boostrapping and no mechanism to provision these
configurations to a private CM and in fact all configuration is done in code
and it is very complex.
-> we should centralize configuration in a well documented format with a simple
default case and possible extension.
Management Agent extension:
Bringing in extensions or customization on the bundle classpath is very hard on
only partially possible. There is a mechanism to disabled activators and one to
add custom ones. Theoretically one could also provide services from "user
space", but there is no way do do so in a simple way as there are no visible
APIs and the CM catch-22.
-> We should simplify extension on bundle classpath through a simple factory
SPI. Bringing these on the classpath can be done through wrapping (as launcher
does) or maybe also fragment bundles.
-> User space extensions could have a real use case in management/monitoring.
However, this means we need to expose some API. Question is whether we want to
expose prg.apache.ace.* (or some subset) so that consumers can talk to for
exmaple Log directly or that we should facade this behind a single
ManagementAgent API to keep it more contained.
Multiple agents:
There is code to configure and handle multiple agents. Not sure if it really
works as it is a very exotic and possibly undesirable use-case. There are many
conditionals for this through the CM code.
-> At least make it simpler and discuss wither we actually want/need this at
all.
Resource Processors:
RPs need to resolve, typically requiring framework, deploymentadmin (spi) and
eventadmin, but maybe more. In the current situation the MA exports these
package with an additional required attribute (managementagent=true). As a
result standard 3rd party RPs will not resolve. Therefore the MA should be as
self-contained as possible but still export these packages without the
attribute and (re)import them with the appropriate range.
-----------------------------------
UPDATE 10/8
Restarted this effort @see
https://cwiki.apache.org/confluence/display/ACE/Analysis+and+Design+for+new+ManagementAgent
was:
The Managent Agent was made "self-contained" in ACE-232 but there are still
some concerns with regard to complexity and functionality. This issue deals
with restructuring the Managent Agent code to make it easier to maintain,
configure and extend. Also see ACE-324 / ACE-324.
Management Agent code:
The MA implementation is setup very modular and it assembled mainly based on CM
factories. Maybe a little too much. The code is scattered over projects making
it hard to maintain and it is violating visibility rules to implementation
classes which is nasty in bndtools.
-> We should centralize the 'dedicated' MA code in the MA project allowing us
to clean up a lot of projects.
Management Agent config:
The fact that we can theoretically reconfigure these services at runtime
through CM does not add much more then a runtime dependency on a CM impl. There
is an obvisou catch-22 in boostrapping and no mechanism to provision these
configurations to a private CM and in fact all configuration is done in code
and it is very complex.
-> we should centralize configuration in a well documented format with a simple
default case and possible extension.
Management Agent extension:
Bringing in extensions or customization on the bundle classpath is very hard on
only partially possible. There is a mechanism to disabled activators and one to
add custom ones. Theoretically one could also provide services from "user
space", but there is no way do do so in a simple way as there are no visible
APIs and the CM catch-22.
-> We should simplify extension on bundle classpath through a simple factory
SPI. Bringing these on the classpath can be done through wrapping (as launcher
does) or maybe also fragment bundles.
-> User space extensions could have a real use case in management/monitoring.
However, this means we need to expose some API. Question is whether we want to
expose prg.apache.ace.* (or some subset) so that consumers can talk to for
exmaple Log directly or that we should facade this behind a single
ManagementAgent API to keep it more contained.
Multiple agents:
There is code to configure and handle multiple agents. Not sure if it really
works as it is a very exotic and possibly undesirable use-case. There are many
conditionals for this through the CM code.
-> At least make it simpler and discuss wither we actually want/need this at
all.
Resource Processors:
RPs need to resolve, typically requiring framework, deploymentadmin (spi) and
eventadmin, but maybe more. In the current situation the MA exports these
package with an additional required attribute (managementagent=true). As a
result standard 3rd party RPs will not resolve. Therefore the MA should be as
self-contained as possible but still export these packages without the
attribute and (re)import them with the appropriate range.
> Redesign Management Agent
> -------------------------
>
> Key: ACE-347
> URL: https://issues.apache.org/jira/browse/ACE-347
> Project: ACE
> Issue Type: Improvement
> Reporter: Bram de Kruijff
> Assignee: Bram de Kruijff
>
> The Managent Agent was made "self-contained" in ACE-232 but there are still
> some concerns with regard to complexity and functionality. This issue deals
> with restructuring the Managent Agent code to make it easier to maintain,
> configure and extend. Also see ACE-324 / ACE-324.
> Management Agent code:
> The MA implementation is setup very modular and it assembled mainly based on
> CM factories. Maybe a little too much. The code is scattered over projects
> making it hard to maintain and it is violating visibility rules to
> implementation classes which is nasty in bndtools.
> -> We should centralize the 'dedicated' MA code in the MA project allowing us
> to clean up a lot of projects.
> Management Agent config:
> The fact that we can theoretically reconfigure these services at runtime
> through CM does not add much more then a runtime dependency on a CM impl.
> There is an obvisou catch-22 in boostrapping and no mechanism to provision
> these configurations to a private CM and in fact all configuration is done in
> code and it is very complex.
> -> we should centralize configuration in a well documented format with a
> simple default case and possible extension.
> Management Agent extension:
> Bringing in extensions or customization on the bundle classpath is very hard
> on only partially possible. There is a mechanism to disabled activators and
> one to add custom ones. Theoretically one could also provide services from
> "user space", but there is no way do do so in a simple way as there are no
> visible APIs and the CM catch-22.
> -> We should simplify extension on bundle classpath through a simple factory
> SPI. Bringing these on the classpath can be done through wrapping (as
> launcher does) or maybe also fragment bundles.
> -> User space extensions could have a real use case in management/monitoring.
> However, this means we need to expose some API. Question is whether we want
> to expose prg.apache.ace.* (or some subset) so that consumers can talk to for
> exmaple Log directly or that we should facade this behind a single
> ManagementAgent API to keep it more contained.
> Multiple agents:
> There is code to configure and handle multiple agents. Not sure if it really
> works as it is a very exotic and possibly undesirable use-case. There are
> many conditionals for this through the CM code.
> -> At least make it simpler and discuss wither we actually want/need this at
> all.
> Resource Processors:
> RPs need to resolve, typically requiring framework, deploymentadmin (spi) and
> eventadmin, but maybe more. In the current situation the MA exports these
> package with an additional required attribute (managementagent=true). As a
> result standard 3rd party RPs will not resolve. Therefore the MA should be as
> self-contained as possible but still export these packages without the
> attribute and (re)import them with the appropriate range.
> -----------------------------------
> UPDATE 10/8
> Restarted this effort @see
> https://cwiki.apache.org/confluence/display/ACE/Analysis+and+Design+for+new+ManagementAgent
--
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
