[
https://issues.apache.org/jira/browse/ACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651738#comment-13651738
]
Bram de Kruijff commented on ACE-347:
-------------------------------------
Added launcher under projects org.apache.ace.agent.launcher and some config/spi
refactoring to properly support it in r1480190
> 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.
>
--
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
