You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carsten Ziegeler <cz...@apache.org> on 2013/01/25 10:33:18 UTC
Separating configuration status support from web console
Hi,
I've created a first implementation[1] of a new bundle which takes
over the configuration status functionality from the web console
The configuration status printers in the web console are imho of more
general use, and make sense to be used outside of a web console.
I've created a new API which is similar to the current configuration
printer api but a little bit more consistent and more trimmed to the
actual use cases.
In addition to the API and the implementation thereof, I've provided
several glue code:
a) web console configuration printers are registered as the new service
b) a new web console plugin for the configuration status which uses
the new services. Due to a) old API is supported as well
c) configuration printers are now registered as separate web console
plugins, so we have a menu entry for each status which makes getting
to a specific status easier
d) The web console stuff is as compatible as possible, same urls for
zip etc. are used, same functionality
e) The only thing the new api does not support anymore is
localization. I think for a configuration status, it's better to stick
to one language.
f) Added new support for printers providing machine readable json.
WDYT?
Regards
Carsten
[1] https://svn.apache.org/repos/asf/felix/sandbox/cziegeler/status-printer
--
Carsten Ziegeler
cziegeler@apache.org
Re: Separating configuration status support from web console
Posted by Carsten Ziegeler <cz...@apache.org>.
If people find this is a good way to go forward, we could
a) move the code to trunk (where?)
b) add it to the web console and remove the configuration status printer plugin
c) deprecate all configuration status stuff in the web console
This would allow us to get a web console including this stuff for
further testing/improvements.
Regards
Carsten
2013/1/25 Carsten Ziegeler <cz...@apache.org>:
> 2013/1/25 Felix Meschberger <fm...@adobe.com>:
>> Hi,
>>
>> Thanks alot.
>>
>> From a modularization POV this makes a lot of sense and I agree with the direction you are taking here.
>>
>> From an ease-of-use POV, it is a bit different: For the 4.0 release we dropped the full build. This causes some trouble in the community because it is now harder to deploy the Web Console in simple setups. So the next release will have an all-in-one bundle again.
>>
>> So, about all-in-one: would it make sense and would it be possible to setup the Web Console all-in-one build such, that the new external bundle would be part of the webconsole all-in-one bundle again ?
>
> Yes, it's just one more bundle to add - it has zero dependencies
> (apart from framework classes).
>
> Carsten
>
>>
>> Regards
>> Felix
>>
>>
>> Am 25.01.2013 um 01:33 schrieb Carsten Ziegeler:
>>
>>> Hi,
>>>
>>> I've created a first implementation[1] of a new bundle which takes
>>> over the configuration status functionality from the web console
>>>
>>> The configuration status printers in the web console are imho of more
>>> general use, and make sense to be used outside of a web console.
>>>
>>> I've created a new API which is similar to the current configuration
>>> printer api but a little bit more consistent and more trimmed to the
>>> actual use cases.
>>> In addition to the API and the implementation thereof, I've provided
>>> several glue code:
>>> a) web console configuration printers are registered as the new service
>>> b) a new web console plugin for the configuration status which uses
>>> the new services. Due to a) old API is supported as well
>>> c) configuration printers are now registered as separate web console
>>> plugins, so we have a menu entry for each status which makes getting
>>> to a specific status easier
>>> d) The web console stuff is as compatible as possible, same urls for
>>> zip etc. are used, same functionality
>>> e) The only thing the new api does not support anymore is
>>> localization. I think for a configuration status, it's better to stick
>>> to one language.
>>> f) Added new support for printers providing machine readable json.
>>>
>>> WDYT?
>>>
>>> Regards
>>> Carsten
>>>
>>> [1] https://svn.apache.org/repos/asf/felix/sandbox/cziegeler/status-printer
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: Separating configuration status support from web console
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/1/25 Felix Meschberger <fm...@adobe.com>:
> Hi,
>
> Thanks alot.
>
> From a modularization POV this makes a lot of sense and I agree with the direction you are taking here.
>
> From an ease-of-use POV, it is a bit different: For the 4.0 release we dropped the full build. This causes some trouble in the community because it is now harder to deploy the Web Console in simple setups. So the next release will have an all-in-one bundle again.
>
> So, about all-in-one: would it make sense and would it be possible to setup the Web Console all-in-one build such, that the new external bundle would be part of the webconsole all-in-one bundle again ?
Yes, it's just one more bundle to add - it has zero dependencies
(apart from framework classes).
Carsten
>
> Regards
> Felix
>
>
> Am 25.01.2013 um 01:33 schrieb Carsten Ziegeler:
>
>> Hi,
>>
>> I've created a first implementation[1] of a new bundle which takes
>> over the configuration status functionality from the web console
>>
>> The configuration status printers in the web console are imho of more
>> general use, and make sense to be used outside of a web console.
>>
>> I've created a new API which is similar to the current configuration
>> printer api but a little bit more consistent and more trimmed to the
>> actual use cases.
>> In addition to the API and the implementation thereof, I've provided
>> several glue code:
>> a) web console configuration printers are registered as the new service
>> b) a new web console plugin for the configuration status which uses
>> the new services. Due to a) old API is supported as well
>> c) configuration printers are now registered as separate web console
>> plugins, so we have a menu entry for each status which makes getting
>> to a specific status easier
>> d) The web console stuff is as compatible as possible, same urls for
>> zip etc. are used, same functionality
>> e) The only thing the new api does not support anymore is
>> localization. I think for a configuration status, it's better to stick
>> to one language.
>> f) Added new support for printers providing machine readable json.
>>
>> WDYT?
>>
>> Regards
>> Carsten
>>
>> [1] https://svn.apache.org/repos/asf/felix/sandbox/cziegeler/status-printer
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Separating configuration status support from web console
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Thanks alot.
>From a modularization POV this makes a lot of sense and I agree with the direction you are taking here.
>From an ease-of-use POV, it is a bit different: For the 4.0 release we dropped the full build. This causes some trouble in the community because it is now harder to deploy the Web Console in simple setups. So the next release will have an all-in-one bundle again.
So, about all-in-one: would it make sense and would it be possible to setup the Web Console all-in-one build such, that the new external bundle would be part of the webconsole all-in-one bundle again ?
Regards
Felix
Am 25.01.2013 um 01:33 schrieb Carsten Ziegeler:
> Hi,
>
> I've created a first implementation[1] of a new bundle which takes
> over the configuration status functionality from the web console
>
> The configuration status printers in the web console are imho of more
> general use, and make sense to be used outside of a web console.
>
> I've created a new API which is similar to the current configuration
> printer api but a little bit more consistent and more trimmed to the
> actual use cases.
> In addition to the API and the implementation thereof, I've provided
> several glue code:
> a) web console configuration printers are registered as the new service
> b) a new web console plugin for the configuration status which uses
> the new services. Due to a) old API is supported as well
> c) configuration printers are now registered as separate web console
> plugins, so we have a menu entry for each status which makes getting
> to a specific status easier
> d) The web console stuff is as compatible as possible, same urls for
> zip etc. are used, same functionality
> e) The only thing the new api does not support anymore is
> localization. I think for a configuration status, it's better to stick
> to one language.
> f) Added new support for printers providing machine readable json.
>
> WDYT?
>
> Regards
> Carsten
>
> [1] https://svn.apache.org/repos/asf/felix/sandbox/cziegeler/status-printer
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Separating configuration status support from web console
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 25.01.2013 um 04:42 schrieb Bertrand Delacretaz:
> On Fri, Jan 25, 2013 at 10:33 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I've created a first implementation[1] of a new bundle which takes
>> over the configuration status functionality from the web console...
> ...
>> WDYT?...
>
> AFAIK the current configuration status tabs don't have their own URL,
> the only way to access them is by clicking their tab on the main
> config page.
>
> If I'm correct, is that something that your changes address, or is
> that unrelated?
Yes, that would be an additional benefit of this change AFAICT.
Regards
Felix
Re: Separating configuration status support from web console
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 25, 2013 at 10:33 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I've created a first implementation[1] of a new bundle which takes
> over the configuration status functionality from the web console...
...
> WDYT?...
AFAIK the current configuration status tabs don't have their own URL,
the only way to access them is by clicking their tab on the main
config page.
If I'm correct, is that something that your changes address, or is
that unrelated?
-Bertrand