History

The Felix Web Console was created out of a need for having  web based tool to manage as many aspects of an application deployed in an OSGi Framework as possible. The concrete example was Apache Sling. Over time the need generalized and the Web Console became the Apache Felix Web Console.

Today, the Web Console has several aspects but also shows some age and problems:

• The Web Console is easily extensible from as raw as simple Servlet API Servlets to more elaborate extensions of the AbstractWebConsoleServlet
• The original status printer has evolved into its own inventory plugin world
• Extensions to the Web Console generally mix server side and client side components in a single servlet
• Client Side "intelligence" is very crude and based and based on very low level JQuery
• Evolution shows signs of legacy and cruft

Proposal

I propose to create a new Web Console infrastructure:

• Define proper HTTP-based, REST-full if possible, API to access the framework information
  • Use existing OSGi REST-full API proposals as the basis
  • Leverage OSGi DTO data model
• Implement its own client side UI framework infrastructure
• Define an extension model, where additional information may be included in sort of a tree-view which can be drilled down into
• Core Web Console should only expose core OSGi Framework information, basically just supporting the Module (bundles), Lifecycle, and Service layer of the OSGi framework model.
• Investigate an access control model which can be laid on top of the REST-full API
  • Assuming basic model is CRUD on resources, access levels are creation, read, update, and deletion
  • Discuss group and/or role model
  • Integrate with OSGi User Admin Service – extend service if needed/required
• Client Side UI framework should as well be based on an extension model, where the basic styling should be centralized and taken out of the client side rendering. Models in this respect would be AngularJS and/or React.JS.