CODEWITHSUNDEEP
osgideclarative-services
Shashi
Shashi

Reputation: 746

OSGi: when to use component framework and when to create objects yourself

I've been an AEM developer for almost a year now. I know AEM uses 'Declarative Services component framework' to manage life cycle of OSGi components.

Consider a scenario when i would export a package from a bundle and import that package from another bundle, i could create objects of classes in first bundle inside second bundle as well. it's a import-export contract in this case.
my question is when i should be using component framework to manage the lifecycle of my objects and when to handle it myself by creating them when required.

Upvotes: 1

Views: 149

Answers (2)

Neil Bartlett
Neil Bartlett

Reputation: 23948

In an ideal design, you would NOT in fact be able to create objects from the exported package; because that package would contain only interfaces. This makes it a "pure" contract (API) export. If there are classes in there that you can directly instantiate, then they are implementation classes.

In general it is far better to export only pure APIs and to keep implementation classes hidden. There are two main reasons:

  1. Implementation classes tend to have downstream dependencies. If you depend directly from implementation class to implementation class then you get a very large and fragile dependency graph... and eventually that graph will contain a cycle. In fact it's almost inevitable that it will. At that point, your application is not modular because you cannot deploy or change any part of it independently.

  2. Pure interfaces can be analysed for compatibility between versions. As a consumer or a provider of an API, you know exactly which versions of the API you can support because the API does not contain executable code. However if you have a dependency onto an implementation class, then you never really know when they break compatibility because the breakage could happen deep down in executable code that you can't easily analyse.

Upvotes: 3

Bertrand Delacretaz
Bertrand Delacretaz

Reputation: 6100

If your objects are services then there's no question, they have to be OSGi components.

For other things, my first choice is OSGi components, unless they're trivial objects like data holders or something similar.

If an object requires configuration or refers to OSGi services then it's also clearly an OSGi component.

In general, it's best IMO to think in services and define your package exports as the minimum that allows other bundles to use a bundle's services. Unless a bundle is clearly a reusable library like commons-io (to take a simple example).

Upvotes: 3

Related Questions