You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@adobe.com> on 2011/09/08 08:51:26 UTC
[WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
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
(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
- Preferences Service
- Wire Admin
- 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.
Now, that we started breaking out plugins, we should probably be
consequent and break out non-central plugins.
Regards
Felix
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
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.
Ok
>> - 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.
Regards
Felix
>> Now, that we started breaking out plugins, we should probably be
>> consequent and break out non-central plugins.
>>
>> Regards
>> Felix
>>
>>
>
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Valentin,
On 12.09.2011 16:52, Valentin Valchev wrote:
> Hello Felix,
> I've just committed the new plugins and removed the old code from
> webconsole.
Cool.
> Didn't resolved this issue: https://issues.apache.org/jira/browse/FELIX-3111
> because there is no version in Jira for obr-plugin. Can you add one?
I have created the webconsole-obr-plugin 1.0.0 version.
> I also don't know how to add these plugins to build by default. Is there
> something like main pom file that builds everything related to the
> apache felix project?
There is a reactor pom.xml in the root folder. It currently only lists
the events plugin and none of the other new plugin projects.
To be honest, I never really use the reactor to build everything. Rather
I just build on demand and otherwise just use released versions of the
bundles in my projects.
Which leads me to suggesting that we soon release the stuff ;-)
Regards
Felix
> Regards,
> Valentin Valchev
>
>
> On 12.9.2011 г. 14:42 ч., Felix Meschberger wrote:
>> Hi,
>>
>> On 12.09.2011 08:52, Valentin Valchev wrote:
>>> Hi Felix,
>>> I have the following plugins already separated:
>>> deppack
>>> ds (declarative services)
>>> shell
>>> obr
>>>
>>> The question is can I commit now?
>> Sure, go ahead.
>>
>> Regards
>> Felix
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
On 12.09.2011 08:52, Valentin Valchev wrote:
> Hi Felix,
> I have the following plugins already separated:
> deppack
> ds (declarative services)
> shell
> obr
>
> The question is can I commit now?
Sure, go ahead.
Regards
Felix
> Regards,
> Valentin
>
> On 9.9.2011 г. 18: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.
>>> (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.
>>> - 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.
>>> Now, that we started breaking out plugins, we should probably be
>>> consequent and break out non-central plugins.
>>>
>>> Regards
>>> Felix
>>>
>>>
>
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Valentin Valchev <v_...@prosyst.bg>.
Hi Felix,
I have the following plugins already separated:
deppack
ds (declarative services)
shell
obr
The question is can I commit now?
Regards,
Valentin
On 9.9.2011 г. 18: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.
>> (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.
>> - 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.
>> Now, that we started breaking out plugins, we should probably be
>> consequent and break out non-central plugins.
>>
>> Regards
>> Felix
>>
>>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Valentin Valchev <v_...@prosyst.bg>.
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.
>
> (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.
> - 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.
>
> Now, that we started breaking out plugins, we should probably be
> consequent and break out non-central plugins.
>
> Regards
> Felix
>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------