Mailing-List: contact commits-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ace.apache.org
Date: Tue, 13 Aug 2013 14:17:50 +0000 (UTC)
From: "Wilfried.Sibla@bosch-si.com (JIRA)" <jira@apache.org>
To: commits@ace.apache.org
Message-ID: <JIRA.12646367.1367914004420.55199.1376403469997@arcas>
In-Reply-To: <JIRA.12646367.1367914004420@arcas>
References: <JIRA.12646367.1367914004420@arcas>
Subject: [jira] [Commented] (ACE-347) Redesign Management Agent
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/ACE-347?page=3Dcom.atlassian.ji=
ra.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1373826=
9#comment-13738269 ]=20

Wilfried.Sibla@bosch-si.com commented on ACE-347:
-------------------------------------------------

=EF=BB=BF
Vielen Dank f=C3=BCr Ihre Email. Leider bin ich bis zum 30.08.'13 nicht im =
B=C3=BCro.
Ihre Email wird nicht weitergeleitet! Bei Fragen wenden Sie sich bitte tele=
fonisch an unsere Zentrale unter der Rufnummer +49 7545 202-300.

Thank you for your email. I'm out of the office until 2013-08-30
Your email won't be fowarded! Please call +49 7545 202-300 for any question=
s.

Mit freundlichen Gr=C3=BC=C3=9Fen / Best regards

Wilfried Sibla

Bosch Software Innovations GmbH
Development Software - Core Products Waiblingen (INST/DSW-Wa)

Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de<http://www.bosch-si.de/>

Tel.:      +49 7545 202-325
Mobil:   +49 172 2577 205
Fax:     +49 7545 202-301
Wilfried.Sibla@bosch-si.de<mailto:Wilfried.Sibla@bosch-si.de>

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB =
148411 B
Executives: Heinz Derenbach; Thomas Cotic, Michael Hahn, Klaus H=C3=BCftle

               =20
> 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 sti=
ll some concerns with regard to complexity and functionality. This issue de=
als with restructuring the Managent Agent code to make it easier to maintai=
n, configure and extend. Also see ACE-324 / ACE-324.
> Management Agent code:  =20
> 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 proje=
cts making it hard to maintain and it is violating visibility rules to impl=
ementation classes which is nasty in bndtools.
> -> We should centralize the 'dedicated' MA code in the MA project allowin=
g us to clean up a lot of projects.
> Management Agent config:  =20
> 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. T=
here is an obvisou catch-22 in boostrapping and no mechanism to provision t=
hese configurations to a private CM and in fact all configuration is done i=
n code and it is very complex.=20
> -> we should centralize configuration in a well documented format with a =
simple default case and possible extension.
> Management Agent extension:  =20
> Bringing in extensions or customization on the bundle classpath is very h=
ard 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 ar=
e no visible APIs and the CM catch-22.
> -> We should simplify extension on bundle classpath through a simple fact=
ory SPI. Bringing these on the classpath can be done through wrapping (as l=
auncher does) or maybe also fragment bundles.
> -> User space extensions could have a real use case in management/monitor=
ing. 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 tal=
k to for exmaple Log directly or that we should facade this behind a single=
 ManagementAgent API to keep it more contained.
> Multiple agents:  =20
> There is code to configure and handle multiple agents. Not sure if it rea=
lly works as it is a very exotic and possibly undesirable use-case. There a=
re 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 th=
ese package with an additional required attribute (managementagent=3Dtrue).=
 As a result standard 3rd party RPs will not resolve. Therefore the MA shou=
ld be as self-contained as possible but still export these packages without=
 the attribute and (re)import them with the appropriate range.
> -----------------------------------=20
> UPDATE 10/8
> Restarted this effort @see https://cwiki.apache.org/confluence/display/AC=
E/Analysis+and+Design+for+new+ManagementAgent

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira