felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: [suggestion] - OSGI WebConsole
Date Wed, 02 Mar 2011 21:28:23 GMT
On 02.03.11 18:37, "Charles Moulliard" <cmoulliard@gmail.com> wrote:
>(2) Switch the existing architectural model to use frameworks like
>Apache Wicket or Vaadin where the content is clearly separated from
>the server side code. Apache Wicket and Vaadin librairies are already
>osgified so their integration in project like karaf, sling or felix
>will be done seamless even if we have the overhead to deploy them. But
>this is also the same for bundles like PAX-Web, ...

>From a Sling perspective, which is a web application framework, using
Sling to render the web console pages would be cool :-)

However, I think there is a good reason that the web console
implementation(s) are as simple as possible: if they rely on too much
external bundles and services, chances are higher that things can break.
The console is typically an important management interface that should
always be running, even if the system it manages is mostly down (because
bundles are updating, not resolved etc.). So if it is for example used to
manage Sling, but also run by Sling, you get cyclic dependency hell and if
Sling is down, the console has a problem, too.

One could also embed those libraries in the web console bundle(s), but
then you have to do it every single time, as most screens are provided as
plugins, residing in their own bundles. Thus bundle sizes explode and
version management can be difficult.

So I think one should be careful in adding complex dependencies.

The current plain servlets are very robust in this regard. But I agree
that not having a templating mechanism such as JSP makes it hard to work
on it.

Just my 2 cents,

Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

View raw message