Skip to content
This repository has been archived by the owner on Oct 5, 2022. It is now read-only.

Fabric8 API SPI

tdiesler edited this page Sep 29, 2014 · 6 revisions

This is work in progress


Defining an API/SPI for Fabric is work in progress. Here we can start to collect requirements on API/SPI constructs

Usable by clients

Many of the construct that Fabric8 internally depend on volatile OSGi services. They work in the context of other SCR services that have a dependency on them. Clients can however not use these constructs reliably because they can deactivate any time (and never activate again).

Reliably accessible endpoints

Http, JMX, Commands and other endpoints must be reliably accessible. Clients should not get exposed to the volatile nature of services that these endpoints depend on.

Functional correctness

The usage of API/SPI must allow to transition the system from one consistent state to the next. Concurrency contracts must be properly documented and implemented in line with what is documented.

Stable Signature

Clients like to have stable API/SPI signatures. Proposed changes to API/SPI must be reviewed carefully for backward compatibility

Non Java API

API also includes definitions of other access points and signatures. These would for example be REST URIs and data exchange format, XML schemas, command syntax, data store layout (when direct access is permitted), etc. The complete closure of stable API should be defined.