[
https://issues.apache.org/jira/browse/ACE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13660545#comment-13660545
]
Marcel Offermans commented on ACE-347:
--------------------------------------
I think we need to keep our options open to do both. Embedding the management
agent inside the launcher is very convenient for people that want to start with
a plain OSGi container (Felix, Equinox, Knopflerfish). However, having a MA
bundle that you can drop into any OSGi environment also is a use case we want
to support (for example, you might want to drop it in a Java EE appserver like
Glassfish).
Regarding suggestions, Wilfried, you can either supply them here, or subscribe
to the [email protected] mailing list as explained here:
http://ace.apache.org/get-involved/mailing-lists.html .
> 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
