felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105) WebConsole bundle should export packages from embedded jars)
Date Mon, 12 Sep 2011 11:41:55 GMT

On 09.09.2011 17:59, Valentin Valchev wrote:
> Hello,
> On 8.9.2011 г. 09:51 ч., Felix Meschberger wrote:
>> Hi all,
>> On 07.09.2011 20:26, Valentin Valchev wrote:
>>> Btw what about the OBR plugin? Shall it remain build-in or moved as
>>> separate plugin?
>> Now, this starts to be an interesting discussion ;-)
>> This is the current plugin setup in the Web Console:
>> (1) Plugins I consider core and which should be kept:
>> - Bundle
>> - Services
>> - License
>> - System Properties
> Thinking of that, maybe we can add also another one - Framework
> Properties, that the user can obtain from
> BundleContext.getProperty(String key), since framework properties are
> important, but it's not actually necessary to be system properties.
The problem here is, that there is no way to enumerate the framework
properties (as in BundleContext.getPropertyNames() or similar). So, the
only thing you can do is print a number of well-known properties....
>> (2) Plugins already considered for breaking out
>> - Deployment Admin -- FELIX-3099
>> - DS - FELIX-3100
>> - Shell - FELIX-3107
>> (3) Plugins still in the Web Console which might/should be split off
>> - Configuration Admin
>> - LogService
> I think that these should be build-in. Configuration and Log service are
> so common, that we can make them available by default.
>> - Preferences Service
>> - Wire Admin
> Could go into common bundle 'compendium plugins'. So with one bundle you
> can install almost all OSGi-related plugins/printers.
We have split most compendium supports in separate bundles and keep to
inline (LogService, Configuration Admin). I think it would be strange to
move these two in a single bundle ...
>> - Thread
>> - OBR
>> The idea of also breaking out the Thread configuration printer is to
>> easier support thread dump funcitonality introduced with Java 5 and 6
>> through the JMX Thread API. Also this could be aligned with the Apache
>> Kato project, particularly KATO-14.
> Yes, but still Thread information is general information, that can be
> used for system analysis and the information will be still usable, if
> you  don't have that JMX API. So I vote for leaving Thread info into the
> main web console. Additional functionality could be provided by separate
> bundle - like that memory plugin, that already uses the JMX API I think.
Arguably, yes. So lets keep it inside for now.

>> Now, that we started breaking out plugins, we should probably be
>> consequent and break out non-central plugins.
>> Regards
>> Felix

View raw message