[MDSAL-413] Add blueprint component Created: 08/Jan/19 Updated: 22/Feb/20 Resolved: 22/Feb/20 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | blueprint |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
We have migrated blueprint extension from the controller project. We need to adjust it to work with MD-SAL interfaces and to occupy different namespaces. As part of this, we need to split up the extension into at least two parts, because it combines generic concepts (like static-reference) and binding concepts (like rpc-service). |
| Comments |
| Comment by Robert Varga [ 22/Feb/20 ] |
|
The basic mindset behind blueprint goes directly against MD-SAL's view of immutable objects. Specifically, hides all dynamic services behind proxies, isolating us from the Service Registry. Hence we cannot use the registry to exchange state – which defeats the point of having the service registry. OSGi Declarative Services use static binding (by default) and allow us to expose component lifecycle, so that it can be correctly responded to. We therefore remove any pretense we are endorsing blueprint – because we are not. Everybody should decompose their application properly and use DS for OSGi. |